Tidligere refererte repoet til dokumentasjon som lå utenfor (i Salg/_mal/), og brukte Obsidian-wikilinks [[...]] som ikke er klikkbare i Gitea. Begge deler gjorde at lenker var døde i Gitea-web. Endringer: - Hentet inn arbeidsdokumentene som faktisk brukes under oppdraget: _metode/ (00-konvensjoner, 01-startklar-sjekkliste, 02-gjennomforing) artefakter/ (risikoregister, integrasjonslandskap, workshop-agenda, domenemodell-skjema) - Konverterte 82 Obsidian-wikilinks til standard markdown-lenker med korrekte relative stier — klikkbare både i Gitea og lokalt - Begrepsord i begrepskatalogen ([[Bedrift]] etc.) ble til ren tekst (de var aldri filer) - Oppdaterte konvensjonsdokumentet til å foreskrive standard markdown, ikke wikilinks (med begrunnelse: Gitea rendrer ikke [[...]]) - Oras/Kirken/salgsmateriale er nå tydelig merket som eksterne arbeidsområde-referanser (andre kunder / salgsfase), ikke dinglende lenker som lot som de var i repoet Verifisert: 133 ekte interne lenker resolver korrekt. De 4 gjenværende treffene i validering er kodeeksempler i backticks (viser lenke-syntaks), ikke faktiske lenker. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
70 lines
2.1 KiB
Markdown
70 lines
2.1 KiB
Markdown
---
|
|
title: "Tiltak for innebygd personvern — Standard Online"
|
|
date: "YYYY-MM-DD"
|
|
tags: ["privacy-by-design", "gdpr", "tiltak"]
|
|
refs:
|
|
- "gdpr-oversikt.md"
|
|
- "../4.informasjonsarkitektur/masterdata-og-eierskap.md"
|
|
qa:
|
|
status: "draft"
|
|
version: 1
|
|
---
|
|
|
|
# Tiltak for innebygd personvern
|
|
|
|
GDPR artikkel 25 krever **innebygd personvern (Privacy by Design)** og **personvern som standardinnstilling (Privacy by Default)**.
|
|
|
|
## Privacy by Design — implementerte og pågående tiltak
|
|
|
|
Struktur (basert på DNK-mønster):
|
|
|
|
### 1. Identitet og tilgangsstyring (IAM)
|
|
|
|
*Hvilket IAM-system brukes? Token-basert? Single sign-on? Hvordan styres tilganger til personopplysninger?*
|
|
|
|
### 2. API-sikkerhet
|
|
|
|
*Krever nye API-er autentisering? Hvilke gamle integrasjoner bruker basic auth eller åpne endepunkter?*
|
|
|
|
### 3. Dataminimering
|
|
|
|
*Hvilke API-er/views har versjoner med redusert personinformasjon for konsumenter som ikke trenger fullstendig data?*
|
|
|
|
### 4. Tilgangsstyring per dataområde
|
|
|
|
*Rollebasert? Per system? Per datadomene?*
|
|
|
|
### 5. Logging og sporbarhet
|
|
|
|
*Hva logges av hvem-gjorde-hva-når? Hvor lagres logger? Hvor lenge?*
|
|
|
|
## Privacy by Default
|
|
|
|
*Standardinnstillinger som beskytter personvern uten at brukeren må gjøre noe:*
|
|
|
|
- **Identifikatorbruk:** Brukes personnummer kun der lov krever det? Bruk Person-ID/intern-ID som integrasjonsnøkkel.
|
|
- **Innsamling:** Samles kun nødvendige opplysninger inn?
|
|
- **Lagring:** Hva er standard lagringstid? Slettes automatisk når formålet opphører?
|
|
- **Deling:** Er deling med tredjeparter opt-in?
|
|
|
|
## Mangler og planlagte tiltak
|
|
|
|
Følgende tiltak mangler eller bør prioriteres hos Standard Online:
|
|
|
|
| Tiltak | Status | Begrunnelse | Prioritet |
|
|
|---|---|---|---|
|
|
| Samtykkeforvaltning | | | |
|
|
| Dataportal med personvernklassifisering | | | |
|
|
| DPIA-prosess for nye integrasjoner | | | |
|
|
| Offboarding-rutiner for tilganger | | | |
|
|
| Avvikshåndteringsprosess (72-timersregel) | | | |
|
|
| Behandlingsoversikt | | | |
|
|
|
|
## Anbefalinger
|
|
|
|
*Lenke til [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md) for prioriterte tiltak.*
|
|
|
|
---
|
|
|
|
*Klassifisering: Begrenset*
|