SharePoint rettigheder: En enkel model der stopper kaos

I kender symptomerne: “Jeg kan ikke komme ind i mappen”, “hvem gav adgang til den kunde?”, og IT ender med at gætte sig frem i SharePoint. I 2026 bliver det dyrere, fordi Copilot svarer ud fra alt, brugeren kan læse – også det, der kun var “gemt væk”. Her får I en enkel model for SharePoint rettigheder, der kan forklares på 5 minutter og driftes i årevis.

• Skær permissions sprawl væk: brug kun Owners/Members/Visitors pr. site og stop med unikke tilladelser på mapper.
• Byg fladt: segmentér med flere sites (gerne hub) i stedet for subsites og dybe biblioteksstrukturer.
• Gør ekstern deling sikkert: isolér gæster i egne sites og brug “Specific people” i stedet for “Anyone with the link”.
• Lev op til NIS2 adgangsstyring: planlæg faste reviews af medlemskaber og dokumentér ejerskab pr. site.
• Gør Copilot mere tryg: ryd op i read-adgange, så Copilot ikke finder det, brugere ikke burde se.

Hvorfor SharePoint rettigheder knækker i praksis

De fleste miljøer knækker samme sted: I starter fornuftigt med et Team/Site, og så kommer “lige en undtagelse” på en mappe. Efter 6 måneder har I brudt arv (breaking inheritance), individuelle brugere tilføjet direkte, og gamle ansatte (orphan users) der stadig står i en gruppe.

Microsofts best practice er at styre adgang via grupper og en flad informationsarkitektur. ShareGate peger i deres governance-rapport (2025) på, at brudt arv og orphan users er en væsentlig kilde til sikkerhedsproblemer i Microsoft 365. Og med NIS2 (ENISA, artikel 21) er “vi gennemgår det aldrig” ikke en holdbar politik for adgangsstyring.

Før → Efter #1:
Før: IT tildeler adgang på mappeniveau, og ingen kan forklare hvorfor en bruger kan læse “Ledelse”.
Efter: Adgang gives kun via site-grupper (Owners/Members/Visitors), og dataejer godkender ændringer i faste intervaller. Resultat: færre fejl og hurtigere fejlsøgning, fordi “hvem har adgang?” kan besvares på site-niveau.

Sådan ser en model der holder ud (3-gruppe-modellen)

Hold jer til én regel: Rettigheder styres på site-niveau, ikke på mapper og filer. Brug kun de tre standardniveauer, som alle kan forstå:

1) Owners (Ejere)

• Hvem: 2–4 personer (altid mindst 2), der ejer området forretning/drift.
• Må: ændre medlemmer, struktur og delingsindstillinger på sitet.
• Regel: ingen “personlige ejere”. Brug rollebaserede navne/teams.

2) Members (Medlemmer)

• Hvem: dem der arbejder i området (redigerer, uploader, samarbejder).
• Må: redigere indhold.
• Regel: ingen følsomme “kun læs” biblioteker i samme site. Lav hellere et separat site.

3) Visitors (Besøgende)

• Hvem: dem der kun skal læse (ledelse, økonomi, tværgående).
• Må: læse indhold.
• Regel: hvis Visitors-gruppen bliver stor/uklar, er sitet for bredt. Segmentér.

Beslutningsregel: Hvis I overvejer at give adgang til en mappe “for at undgå at give adgang til resten”, så er I i gang med at skabe teknisk gæld. Opret i stedet et nyt site (eller et nyt Team) med sin egen 3-gruppe-model.

Hvordan vælger I mellem flere sites, hub sites og “vi plejer at lave subsites”?

Gå efter flad arkitektur: flere moderne sites, samlet i en hub for navigation og søgning. Subsites frister, fordi det føles som “mapper”. Men det giver typisk uklar arv, tungere oprydning og dårligere segmentering.

• Brug hub: når I vil samle afdelinger/projekter under fælles navigation, men stadig holde rettigheder adskilt.
• Brug nyt site: når ejerskab, målgruppe eller delingsniveau ændrer sig.
• Undgå subsites: når jeres primære problem er adgangsstyring og overblik.

Tjekliste: SharePoint permissions best practices I kan håndhæve

Brug denne tjekliste som jeres interne “M365 access control policy” for SharePoint. Den kan driftes på Business Premium/Standard – og kan udbygges senere.

Kontrol	Hvad I kigger efter	Hvad I gør hvis den fejler
1) Ingen unikke tilladelser	Biblioteker, mapper og filer arver fra sitet	Reset permissions til arv, og flyt undtagelser til nyt site
2) Ingen direkte brugere	Adgang gives via site-grupper/M365 Groups – ikke individer	Fjern direkte tildelinger og læg brugere i Members/Visitors
3) Tydeligt ejerskab	Min. 2 Owners, og de er navngivet/rollebaserede	Udpeg dataejer + backup-ejer, dokumentér i governance-notat
4) Ekstern deling er isoleret	Gæster ligger i egne samarbejdssites	Flyt gæste-samarbejde ud, begræns adgang i interne sites
5) Delingslinks er kontrolleret	Ingen “Anyone with the link” som standard (CISA anbefaling)	Skift til “Specific people” / “Organization only” og genudsted links
6) Periodisk review	Plan for kvartalsvis/halvårlig gennemgang af medlemmer	Start med manuel review; næste step: Entra ID Access Reviews (P2)
7) Klassificering på container-niveau	Sites/Teams har labels (fx Intern, Fortrolig) og klare regler	Indfør Sensitivity Labels for sites, og bind deling til klassificering

Før → Efter #2:
Før: Et “Projekt 2024” site lever videre med tidligere deltagere og gæster, fordi ingen tør slette noget.
Efter: Når projektet lukker, ændres Members til read-only (Visitors), gæster fjernes, og sitet arkiveres med en dato. Resultat: mindre over-eksponering og færre NIS2-afvigelser ved revision.

Fejl der koster mest: breaking inheritance, gæster og “vi fikser det senere”

Breaking inheritance på mapper

Det føles som den hurtige løsning. I praksis gør det adgangsfejl svære at finde og endnu sværere at dokumentere. Hvis I absolut skal lave en undtagelse, så sæt en udløbsdato og en ejer på undtagelsen – og planlæg at flytte det til et særskilt site.

Gæster i “interne” sites

Eksternt samarbejde er normalt. Isolér det. Opret et site pr. leverandør/kundesamarbejde eller pr. projekt med gæster, og hold interne sites fri for gæster. Kombinér med strengere delingsindstillinger (”Specific people”) og MFA-krav for gæster, hvor det er muligt.

Ingen lifecycle for projekter

Hvis I ikke har en lukke-proces, vokser jeres adgangsflade hvert kvartal. Lav en simpel lifecycle: Aktiv → Lukket (read-only) → Arkiv (kun få) → Slet/retention efter politik.

FAQ: SharePoint tilladelser og styring af adgang

Hvad er den bedste praksis for SharePoint rettigheder i en SMB?

Hold jer til 3-gruppe-modellen pr. site (Owners/Members/Visitors), undgå unikke tilladelser på mapper, og segmentér med flere sites. Kombinér med faste reviews af medlemskaber mindst halvårligt.

Skal vi bruge SharePoint groups eller Microsoft 365 Groups?

Brug M365 Groups/Teams hvor samarbejdet hører til i Teams (chat, møder, kanalstruktur). Brug moderne SharePoint sites til intranet/viden og områder uden behov for Teams-chat. Uanset hvad: tildel adgang via grupper, ikke via individuelle brugere.

Hvornår må man bryde arv (breaking inheritance) i SharePoint?

Kun som midlertidig nødløsning. Sæt en ejer, en udløbsdato og en opgave om at flytte indholdet til et separat site med korrekt målgruppe. Hvis undtagelsen skal være permanent, er strukturen forkert.

Hvordan begrænser vi adgang i SharePoint uden at skabe Shadow IT?

Gør det nemt at gøre det rigtige: tilbyd et standard “eksternt samarbejdssite” til gæster, og et standard “fortroligt site” til interne begrænsninger. Hvis brugerne skal vente en uge på adgang, deler de via private kanaler eller eksterne værktøjer.

Hvordan hænger SharePoint rettigheder sammen med Copilot?

Copilot kan kun bruge det, brugeren har læseadgang til. Derfor er “for bred” Visitors/Member-adgang den reelle risiko. Oprydning i read-adgange og fjernelse af unikke tilladelser er det mest effektive Copilot-sikkerhedstiltag på SharePoint-siden.

Hvad kræver NIS2 ift. adgangsstyring i Microsoft 365?

NIS2 (ENISA, artikel 21) kræver en dokumenteret adgangskontrolpolitik og least privilege. I praksis: definér hvem der må godkende adgang (dataejer), kør periodiske reviews, og dokumentér ændringer/afvigelser – især hvor der er gæster eller følsomme data.

Kan vi automatisere access reviews?

Ja. Start med en fast, manuel proces pr. kvartal/halvår (dataejer godkender Owners/Members/Visitors). Som næste step kan I bruge Entra ID Access Reviews (typisk P2) til at automatisere påmindelser, deadlines og audit-spor.

Sådan implementerer I modellen i jeres tenant (7 skridt)

1. Udpeg ejere: Vælg dataejer pr. site og sikre mindst 2 Owners (ikke person-afhængigt).
2. Stop nye undtagelser: Aftal internt “ingen unikke tilladelser på mapper” fra i dag, også selvom oprydningen tager tid.
3. Kortlæg de værste sites: Find sites med gæster, mange direkte brugere og brudt arv. Prioritér dem først.
4. Reset til standard: Fjern direkte tildelinger, genskab arv, og saml adgang i Owners/Members/Visitors.
5. Segmentér korrekt: Opret nye sites for fortroligt indhold og for eksternt samarbejde, og flyt data ud af “blandede” sites.
6. Hærd deling: Sæt standard deling til “Specific people”/”Organization only”, og ryd op i gamle delingslinks.
7. Planlæg reviews: Læg kvartalsvis/halvårlig review i kalenderen, og beslut om I går videre med Entra Access Reviews.

Hvis I vil have en kort vej til et stabilt setup, kan vi hjælpe med governance, oprydning og drift via drift og compliance – og sikre at jeres SharePoint tilladelser kan forklares til både revisor og brugere.