Dokument-ID: O-07
Versjon og dato: 2026-08-21.1 - 21. august 2026
Leverandør: FlowDule ApS, CVR 46273397
Kontakt: security@flowdule.com
Formål: Denne beskrivelsen gir kunder og brukere en forståelig oversikt over FlowDules sikkerhetsmodell. Den inneholder ikke credentials, nettverksdetaljer, kjente sårbarheter, kundespesifikke konfigurasjoner eller opplysninger som kan svekke sikkerheten. Det bindende sikkerhetsnivået fremgår av den aksepterte databehandleravtalen, kundevedlegget og det versjonsbundne TOMS-vedlegget.
1. Sikkerhetsnivå og risikoprofil
FlowDule er en B2B SaaS-plattform som kan behandle klient-, journal- og helseopplysninger på vegne av behandlere og klinikker. Opplysningenes private karakter krever et høyt, risikobasert og løpende kontrollert sikkerhetsnivå.
Sikkerhetsarbeidet bygger på:
-
konfidensialitet: bare identifiserte og bemyndigede personer og systemer får nødvendig tilgang;
-
integritet: relevante endringer, delinger, slettinger og administrative handlinger skal kunne kontrolleres;
-
tilgjengelighet og robusthet: kritiske data og funksjoner skal kunne gjenopprettes etter dokumenterte og testede prosedyrer;
-
innebygd personvern og personvern som standardinnstilling: minst mulig tilgang, data, deling, oppbevaring og tredjepartsaktivering er utgangspunktet;
-
dokumentert effektivitet: et tiltak anses ikke som verifisert bare fordi det er utformet eller finnes i kode.
2. Ansvarsfordeling
| Part | Primært sikkerhetsansvar |
|---|---|
| FlowDule | Plattform, kode, skymiljø, sikker konfigurasjon, interne tilganger, leverandører, support, backup/gjenoppretting, hendelseshåndtering og bistand til kunden. |
| Kunden | Lovlig formål, bruker- og behandlingsrelasjoner, korrekt faglig profil, lokale enheter og nettverk, brukeradministrasjon, delinger, retention, kontroll av oppslag og lokale nødprosedyrer. |
| Brukeren | Personlig konto, beskyttelse av innlogging og enheter, dataminimering, korrekt bruk, kontroll av KI-utdata og rask rapportering av mistanke. |
| Underdatabehandleren | De avtalte sikkerhets- og personvernforpliktelsene for den konkrete tjenesten og konfigurasjonen. FlowDule fører risikobasert kontroll. |
Kundens ansvar begrenser ikke FlowDules ansvar for egne tiltak. FlowDules sikkerhet erstatter heller ikke kundens plikt til å velge en egnet konfigurasjon og kontrollere egne brukeres lovlige tilgang.
3. Infrastruktur og miljøer
FlowDules sentrale plattform bruker Amazon Web Services. Den aksepterte kombinasjonen av leverandør, tjeneste og region fremgår av Underdatabehandlere og leverandører samt kundens instruksvedlegg.
Utvikling, staging og produksjon behandles som forskjellige miljøer. Produksjon er ikke et testmiljø. Reelle klient- og journaldata skal ikke kopieres til utvikling eller alminnelig test. Test bruker syntetiske eller på annen måte lovlig godkjente og dataminimerte opplysninger.
Endringer i dataflyt, tilgang, nettverk, kryptering, logging, retention, regioner og leverandører krever risikovurdering, relevant test, mulighet for rollback og oppdatert dokumentasjon før frigivelse.
4. Identitet og tilgang
FlowDules sikkerhetsmodell krever:
-
personlige kontoer fremfor delte innloggingsopplysninger;
-
rolle- og relasjonsbasert tilgang etter minste privilegium;
-
multifaktorautentisering for privilegerte og interne produksjonstilganger;
-
sentral validering og begrenset levetid for tilgangstokener;
-
rask sperring ved fratredelse, kompromittering eller bortfall av arbeidsbehov;
-
regelmessig ny vurdering av privilegerte og brede tilganger.
Supporttilgang til kundens innhold skal bare skje ved en konkret og dokumentert sak, etter nødvendig godkjenning, med personlig identitet, kortest mulig varighet og relevant logging. Nødtilgang skal ikke være en skjult permanent administratorrolle.
5. Kunde- og dataseparasjon
FlowDule er en multi-tenant plattform. Kundeadskillelse skal håndheves i de relevante lagene, herunder brukergrensesnitt, API, applikasjonslogikk, database og filtilgang.
Tilgang vurderes både etter kundetilhørighet, rolle, lokasjon og den relevante arbeids- eller behandlingsrelasjonen. En bruker skal ikke få tilgang til en klient bare fordi brukeren tilhører samme kundeorganisasjon, dersom den valgte kundemodellen krever en snevrere relasjon.
Isolasjon testes med positive og negative scenarioer, herunder forsøk på tilgang på tvers av kunder, lokasjoner og roller. Privilegerte database- og supportveier omfattes av samme kontrollprinsipp.
6. Kryptering og hemmeligheter
Kommunikasjon med FlowDule skal beskyttes med moderne transportkryptering. Den godkjente produksjonsbaselinen bruker kryptering i ro for relevante databaser, filer og sensitive felter samt kontrollert nøkkelhåndtering.
Credentials, tokener, krypteringsnøkler og andre hemmeligheter skal ikke lagres i kildekode, alminnelige logger eller brukergrensesnitt. Tilgang til hemmeligheter gis etter behov, registreres og roteres ved kompromittering og etter den godkjente nøkkelplanen.
Den konkrete kryptografiske implementeringen, migrasjonsstatusen og nøkkeltilgangen dokumenteres i det konfidensielle TOMS- og evidensmaterialet og utleveres bare etter behov via sikker kanal.
7. Logging og kontroll av tilgang
Relevante handlinger med klient- og journaldata skal kunne spores til en identifisert fysisk bruker eller en entydig systemkomponent. Avhengig av risikoen omfatter dette blant annet lesing, søk, oppretting, endring, nedlasting, eksport, deling, tilbakekalling, sletting og privilegerte administrative handlinger.
Logger skal:
-
inneholde tilstrekkelig kontekst til å undersøke handlingen;
-
unngå journaltekst, passord, tokener, signed URLs og andre unødvendige sensitive verdier;
-
beskyttes mot uautorisert endring og lesing;
-
ha dokumentert oppbevaringsfrist og automatisk sletting;
-
kunne brukes til relevante alarmer, undersøkelser og kundens lovlige kontroll.
Kunden er ansvarlig for å kontrollere egne brukeres arbeidsbetingede oppslag. FlowDule leverer den avtalte funksjonaliteten og bistanden. Kontroll skal være saklig, forholdsmessig og tilgangsbegrenset.
8. Sikker utvikling og endringsstyring
FlowDules utviklingsprosess krever risikobasert kodegjennomgang og test før frigivelse. Avhengig av endringen brukes blant annet automatiserte funksjons- og sikkerhetstester samt skanning av avhengigheter, hemmeligheter, containere og infrastrukturkonfigurasjon.
Funn prioriteres etter sannsynlighet, konsekvens, eksponeringsflate og de behandlede opplysningene. Kritiske forhold medfører blokkering, begrensning eller tilbakeføring av den berørte releasen. Et akseptert unntak skal være tidsbegrenset, ha eier og begrunnelse og registreres i avviksregisteret.
Produksjonsendringer skal kunne kobles til krav, endring, kontrollør, testbevis og frigivelsesbeslutning.
9. Filer og skadelig innhold
Opplastinger begrenses etter filtype, størrelse, signatur og den konkrete funksjonen. Filer og metadata skal ikke kunne brukes til å omgå kundeadskillelse, tilgangskontroll eller sikker filvisning.
Den relevante opplastingsfunksjonen frigis bare med en dokumentert risikobasert løsning for malwarekontroll eller sikker isolasjon/karantene. Filer skal ikke fremstilles som fullt malwarekontrollerte før den faktiske kontrollen er implementert og testet.
10. Leverandør- og overføringssikkerhet
Før en leverandør mottar personopplysninger, vurderer FlowDule minst:
-
juridisk rolle, tjeneste, data og registrerte;
-
avtale, databehandleravtale og relevante sikkerhetsgarantier;
-
behandlingsland, fjernsupport og underleverandørkjede;
-
tilgang, kryptering, logger, retention, sletting, hendelser og exit;
-
eventuelt overføringsgrunnlag og supplerende tiltak.
EU-hosting er ikke alene bevis for at det ikke kan skje overføring til tredjeland. Den aktuelle offentlige leverandørstatusen finnes i Underdatabehandlere og leverandører. Begrensede eller ikke-frigitte funksjoner skal ikke aktiveres med de aktuelle personopplysningene.
11. Backup, gjenoppretting og kontinuitet
FlowDule bruker backup- og gjenopprettingsmekanismer som skal prøves ut i et isolert miljø. En godkjent restoretest skal dokumentere valgt gjenopprettingstidspunkt, faktisk datatap, målt tid, integritet, kundeadskillelse og korrekt gjenbruk av slettinger og legal holds før miljøet åpnes.
FlowDule offentliggjør eller lover ikke bestemte RPO-, RTO-, backup- eller oppetidsmål før de er testet og uttrykkelig avtalt i et SLA eller kundevedlegg. Kundens lokale nødprosedyre skal kunne fungere uten usikre private e-poster, chatter, delte dokumenter eller uautoriserte enheter.
Etter gjenoppretting kontrollerer FlowDule den tekniske fullstendigheten. Kunden kontrollerer egne kritiske faglige opplysninger og gjennomfører nødvendig, sporbar etterregistrering.
12. Sikkerhetshendelser og brudd på personopplysningssikkerheten
Mistanke om tap av konfidensialitet, integritet eller tilgjengelighet behandles som en sikkerhetshendelse. FlowDule registrerer, begrenser, undersøker og dokumenterer hendelsen og bevarer nødvendig bevis uten å skape unødvendige kopier av sensitivt innhold.
Når et brudd på personopplysningssikkerheten gjelder kundens opplysninger, varsler FlowDule kunden uten ugrunnet opphold og leverer tilgjengelige opplysninger i etapper. Kunden beslutter som behandlingsansvarlig melding til tilsynsmyndigheten og informasjon til de registrerte. FlowDules prosedyre skal ikke forsinke kundens mulighet til å overholde sin frist.
Sikkerhetsmistanke rapporteres straks til security@flowdule.com. Alminnelige supportspørsmål sendes til support@flowdule.com.
13. Oppbevaring, sletting og legal hold
Kundens oppbevaringsprofil fastlegges etter faggruppe, land, datakategori og formål. FlowDule bruker ikke automatisk en helserettslig journalfrist på selvstendige psykoterapeuter som ikke er omfattet av den aktuelle særregelen.
Sletting skal omfatte relevante databaser, filer, delinger, køer, cacher, eksportfiler og andre aktive kopier. Backuper utfases gjennom dokumentert rotasjon. Frem til utløp er de beskyttet og skal ikke brukes til andre formål.
Legal hold brukes bare ved en konkret dokumentert plikt, tvist eller lovlig instruks. Det avgrenses til nødvendige personer, objekter og datakategorier, vurderes på nytt regelmessig og oppheves sporbart.
14. KI-sikkerhet
KI-funksjoner er særskilt aktiverte use cases og ikke en generell tilgang til kundens data. Før aktivering dokumenteres modell, versjon, data, regioner, retention, leverandørdeling, ingen trening, kvalitetstest, menneskelig kontroll og stoppregel.
KI-utdata er et utkast. En kompetent bruker skal kontrollere kilden, fakta, negasjoner, tall, datoer, person og faglig kontekst og aktivt godkjenne resultatet. FlowDules KI skal ikke selv treffe diagnose-, triage-, behandlings- eller tilgangsavgjørelser.
Ytterligere informasjon finnes i AI-informasjon.
15. Opplæring og konfidensialitet
Personer med intern eller privilegert tilgang er underlagt konfidensialitet og instrueres før tilgang og deretter regelmessig i blant annet phishing, credentials, journaldata, supporttilgang, logging, hendelser, KI og umiddelbar rapportering.
Tilgang og opplæring dokumenteres. Bevisst misbruk, deling av credentials, omgåelse av kontroller eller fortielse kan medføre umiddelbar stenging av tilgang og relevante kontrakts- eller arbeidsrettslige følger.
16. Dokumentasjon, revisjon og kunder
FlowDule fører et internt kontroll- og evidensregister. Testbevis oppbevares tilgangsbegrenset og omfatter bare nødvendige opplysninger. Åpne forhold registreres med eier, frist, risiko og midlertidig kontroll.
Kunden kan få dokumentasjon og gjennomføre revisjon etter Databehandleravtalen. Kontroll begynner normalt med den aksepterte TOMS, relevante testsammendrag, leverandørdokumentasjon og eventuelle uavhengige erklæringer. Detaljer som kan kompromittere sikkerheten eller andre kunders konfidensialitet, utleveres bare via en egnet sikker og fortrolig prosess.
17. Begrensning av offentlige løfter
Denne beskrivelsen er ikke et SLA og gir ikke i seg selv garanti for bestemt oppetid, gjenopprettingstid, datatapsgrense eller sertifisering. FlowDule påstår ikke ISO 27001-, SOC 2- eller annen sertifisering uten gyldig bevis.
Dersom teksten avviker fra det aksepterte, versjonsbundne TOMS-vedlegget, går TOMS-vedlegget foran for den konkrete kunden. En senere forbedring endrer ikke stilltiende kundens avtalte instruks eller sikkerhetsnivå.