Formål med kontroll 5.20
Kontroll 5.20 styrer hvordan en organisasjon danner en kontrakt forhold til en leverandør, basert på deres sikkerhetskrav og typen leverandører de har å gjøre med.
5.20 er en forebyggende kontroll Det opprettholder risiko ved å etablere gjensidig akseptable forpliktelser mellom organisasjoner og deres leverandører som omhandler informasjonssikkerhet.
Mens Control 5.19 styrer med informasjonssikkerhet hele forholdet er Kontroll 5.20 opptatt av hvordan organisasjoner danner bindende avtaler fra Begynn av et forhold.
Kontrollattributter 5.20
| Kontrolltype | Informasjonssikkerhetsegenskaper | Konsepter for cybersikkerhet | Operasjonelle evner | Sikkerhetsdomener |
|---|---|---|---|---|
| #Forebyggende | #Konfidensialitet | #Identifisere | #Sikkerhet for leverandørforhold | #Governance og økosystem |
| #Integritet | #Beskyttelse | |||
| #Tilgjengelighet |
Eierskap til kontroll 5.20
Eierskap til kontroll 5.20 bør være avhengig av om organisasjonen driver sin egen juridiske avdeling eller ikke, og den underliggende karakteren til enhver signert avtale.
Hvis organisasjonen har juridisk kapasitet til å utarbeide, endre og lagre sine egne kontraktsavtaler uten involvering av tredjepart, bør eierskapet til 5.20 ligge hos personen som har det endelige ansvaret for juridisk bindende avtaler i organisasjonen (kontrakter, memoer om forståelse, SLAer osv.) .)
Hvis organisasjonen outsourcer slike avtaler, bør eierskapet til Control 5.20 ligge hos et medlem av toppledelsen som fører tilsyn med en organisasjonens kommersielle drift, og opprettholder et direkte forhold til en organisasjons leverandører, for eksempel en Chief Operating Officer.
ISO 27001 gjort enkelt
Et forsprang på 81 % fra dag én
Vi har gjort det harde arbeidet for deg, og gir deg 81 % forsprang fra det øyeblikket du logger på. Alt du trenger å gjøre er å fylle ut de tomme feltene.
Generell veiledning om kontroll 5.20
Kontroll 5.20 inneholder 25 veiledningspunkter som ISO oppgir "kan vurderes" (dvs. ikke nødvendigvis alle) for å oppfylle en organisasjons krav til informasjonssikkerhet.
Uavhengig av hvilke tiltak som vedtas, sier Kontroll 5.20 eksplisitt at begge parter skal gå ut av prosessen med en "klar forståelse" av deres informasjonssikkerhetsforpliktelser overfor hverandre.
- Det bør gis en klar beskrivelse som beskriver informasjonen som må få tilgang til på noen måte, og hvordan denne informasjonen skal få tilgang.
- Organisasjonen bør klassifisere informasjonen som skal aksesseres i samsvar med sin publiserte klassifiseringsordning (se kontroll 5.10, kontroll 5.12 og kontroll 5.13).
- Det bør tas tilstrekkelig hensyn til klassifiseringsordningen på leverandørsiden, og hvordan dette forholder seg til organisasjonens klassifisering av informasjon.
- Begge parters rettigheter bør kategoriseres i fire hovedområder – juridisk, lovfestet, regulatorisk og kontraktsmessig. Innenfor disse fire områdene bør ulike forpliktelser være tydelig skissert, som er standard i kommersielle avtaler, inkludert tilgang til PII, immaterielle rettigheter og opphavsrettsbestemmelser. Avtalen bør også dekke hvordan hvert av disse nøkkelområdene skal behandles etter tur.
- Hver part bør være forpliktet til å vedta en rekke samtidige kontroller som overvåker, vurderer og administrerer informasjonssikkerhetsrisiko nivåer (som tilgangskontrollpolicyer, kontraktsgjennomganger, systemovervåking, rapportering og periodisk revisjon). I tillegg bør avtalen tydelig skissere behovet for leverandørpersonell for å overholde en organisasjons informasjonssikkerhetsstandarder (se kontroll 5.20).
- Det bør være en klar forståelse av hva som utgjør både akseptabel og uakseptabel bruk av informasjon, og fysiske og virtuelle eiendeler fra begge parter.
- Det bør etableres prosedyrer som omhandler autorisasjonsnivåene som kreves for at personell på leverandørsiden skal få tilgang til eller se en organisasjons informasjon (f.eks. autoriserte brukerlister, revisjoner på leverandørsiden, servertilgangskontroller).
- Informasjonssikkerhet bør vurderes ved siden av leverandørens egen IKT-infrastruktur, og hvordan dette forholder seg til den type informasjon organisasjonen har gitt tilgang til. risikokriterier og organisasjonens grunnleggende sett med forretningskrav.
- Det bør vurderes hvilke handlinger organisasjonen er i stand til å ta ved kontraktsbrudd fra leverandørens side, eller manglende overholdelse av individuelle krav.
- Avtalen bør tydelig skissere en gjensidig Prosedyre for hendelseshåndtering som tydelig angir hva som skal skje når det oppstår problemer, spesielt når det gjelder hvordan hendelsen kommuniseres mellom begge parter.
- Personell fra begge parter bør gis tilstrekkelig bevisstgjøringstrening (der standard opplæring ikke er tilstrekkelig) på nøkkelområder i avtalen, spesielt når det gjelder nøkkelrisikoområder som Incident Management og tilgang til informasjon.
- Det bør vies tilstrekkelig oppmerksomhet til bruk av underleverandører. Hvis leverandøren har tillatelse til å bruke underleverandører, bør organisasjonene ta skritt for å sikre at slike personer eller selskaper er på linje med det samme sett med informasjonssikkerhetskrav som leverandøren.
- Der det er juridisk mulig og operativt relevant, bør organisasjoner vurdere hvordan leverandørpersonell blir screenet før de samhandler med informasjonen deres, og hvordan screening registreres og rapporteres til organisasjonen, inkludert ikke-screenet personell og områder for bekymring.
- Organisasjoner bør fastsette behovet for tredjepartsattester som bekrefter leverandørens evne til å oppfylle organisatoriske krav til informasjonssikkerhet, inkludert uavhengige rapporter og tredjepartsrevisjoner.
- Organisasjoner bør ha kontraktsmessig rett til å vurdere og revidere en leverandørs prosedyrer, knyttet til kontroll 5.20.
- Leverandører bør ha en forpliktelse til å levere rapporter (med varierende intervaller) som dekker effektiviteten til deres egne prosesser og prosedyrer, og hvordan de har til hensikt å adressere eventuelle problemer som tas opp i en slik rapport.
- Avtalen bør ta skritt for å sikre rettidig og grundig løsning av eventuelle mangler eller konflikter som finner sted i løpet av forholdet.
- Der det er relevant, bør leverandøren operere med en robust BUDR-policy, i tråd med organisasjonens behov, som dekker tre hovedhensyn:
a) Sikkerhetskopieringstype (full server, fil og mappe osv., inkrementell osv.)
b) Sikkerhetskopieringsfrekvens (daglig, ukentlig osv.)
c) Sikkerhetskopieringsplassering og kildemedier (på stedet, utenfor stedet) - Dataresiliens bør oppnås ved å operere med et nødgjenopprettingssted som er atskilt fra leverandørens hoved-IKT-sted, og som ikke er underlagt samme risikonivå.
- Leverandøren bør operere med en omfattende policy for endringsledelse som gir organisasjonen forhåndsvarsling om endringer som kan påvirke informasjonssikkerheten, og gir organisasjonen mulighet til å avvise slike endringer.
- Fysiske sikkerhetskontroller (bygningstilgang, besøkstilgang, romtilgang, skrivebordssikkerhet) bør vedtas som er relevante for hva slags informasjon de har tilgang til.
- Når behovet oppstår for å overføre informasjon mellom eiendeler, nettsteder, servere eller lagringsplasser, bør leverandøren sørge for at data og eiendeler er beskyttet mot tap, skade eller korrupsjon gjennom hele prosessen.
- Avtalen bør skissere en omfattende liste over handlinger som skal iverksettes av begge parter i tilfelle oppsigelse (se også kontroll 5.20), inkludert (men ikke begrenset til):
a) Avhending og/eller flytting av eiendeler
b) Sletting av informasjon
c) Retur av IP
d) Fjerning av tilgangsrettigheter
e) Løpende taushetsplikt - Videre til punkt 23 bør leverandøren skissere nøyaktig hvordan den har til hensikt å ødelegge/permanent slette organisasjonens informasjon i det øyeblikket det ikke lenger er nødvendig (dvs. ved oppsigelse).
- Dersom det ved avtaleslutt oppstår behov for å overlevere støtte og/eller tjenester til en annen leverandør som ikke er oppført på avtalen, iverksettes tiltak for å sikre at prosessen medfører null driftsavbrudd.
Støttekontroller
- 5.10
- 5.12
- 5.13
- 5.20
Supplerende veiledning
For å hjelpe organisasjoner med å administrere leverandørforhold, sier Kontroll 5.20 at organisasjoner bør opprettholde en register over avtaler.
Registrene bør liste opp alle avtaler som holdes med andre organisasjoner, og kategorisert etter forholdets art, som f.eks kontrakter, memorandums of understanding og avtaler om informasjonsdeling.
Administrer all samsvarskontroll, alt på ett sted
ISMS.online støtter over 100 standarder og forskrifter, og gir deg én enkelt plattform for alle dine samsvarsbehov.
Endringer og forskjeller fra ISO 27002:2013
ISO 27002:2022-5.20 erstatter 27002:2013-15.1.2 (Adresser sikkerhet innenfor leverandøravtaler).
ISO 27002:2022-5.20 inneholder en rekke tilleggsveiledninger som omhandler et bredt spekter av tekniske, juridiske og samsvarsrelaterte emner, inkludert:
- Overleveringsprosedyrer
- Ødeleggelse av informasjon
- Oppsigelsesklausuler
- Fysiske sikkerhetskontroller
- Endringsledelse
- Sikkerhetskopier og informasjonsredundans
I store trekk legger ISO 27002:2022-5.20 mye større vekt på hva som skjer på slutten av et leverandørforhold, og legger langt større vekt på hvordan en leverandør oppnår redundans og dataintegritet i løpet av en avtale.
Nye ISO 27002 kontroller
| ISO/IEC 27002:2022 kontrollidentifikator | ISO/IEC 27002:2013 kontrollidentifikator | Kontrollnavn |
|---|---|---|
| 5.7 | NEW | Trusselintelligens |
| 5.23 | NEW | Informasjonssikkerhet for bruk av skytjenester |
| 5.30 | NEW | IKT-beredskap for forretningskontinuitet |
| 7.4 | NEW | Fysisk sikkerhetsovervåking |
| 8.9 | NEW | Konfigurasjonsstyring |
| 8.10 | NEW | Sletting av informasjon |
| 8.11 | NEW | Datamaskering |
| 8.12 | NEW | Forebygging av datalekkasje |
| 8.16 | NEW | Overvåking av aktiviteter |
| 8.23 | NEW | Web-filtrering |
| 8.28 | NEW | Sikker koding |
| ISO/IEC 27002:2022 kontrollidentifikator | ISO/IEC 27002:2013 kontrollidentifikator | Kontrollnavn |
|---|---|---|
| 6.1 | 07.1.1 | Screening |
| 6.2 | 07.1.2 | Vilkår og betingelser for ansettelsen |
| 6.3 | 07.2.2 | Informasjonssikkerhetsbevissthet, utdanning og opplæring |
| 6.4 | 07.2.3 | Disiplinær prosess |
| 6.5 | 07.3.1 | Ansvar etter oppsigelse eller endring av arbeidsforhold |
| 6.6 | 13.2.4 | Avtaler om konfidensialitet eller taushetsplikt |
| 6.7 | 06.2.2 | Fjernarbeid |
| 6.8 | 16.1.2, 16.1.3 | Informasjonssikkerhet hendelsesrapportering |
| ISO/IEC 27002:2022 kontrollidentifikator | ISO/IEC 27002:2013 kontrollidentifikator | Kontrollnavn |
|---|---|---|
| 7.1 | 11.1.1 | Fysiske sikkerhetsomkretser |
| 7.2 | 11.1.2, 11.1.6 | Fysisk inngang |
| 7.3 | 11.1.3 | Sikring av kontorer, rom og fasiliteter |
| 7.4 | NEW | Fysisk sikkerhetsovervåking |
| 7.5 | 11.1.4 | Beskyttelse mot fysiske og miljømessige trusler |
| 7.6 | 11.1.5 | Arbeid i sikre områder |
| 7.7 | 11.2.9 | Oversiktlig skrivebord og oversiktlig skjerm |
| 7.8 | 11.2.1 | Utstyrsplassering og beskyttelse |
| 7.9 | 11.2.6 | Sikkerhet av eiendeler utenfor lokaler |
| 7.10 | 08.3.1, 08.3.2, 08.3.3, 11.2.5 | Lagringsmedier |
| 7.11 | 11.2.2 | Støtteverktøy |
| 7.12 | 11.2.3 | Kablingssikkerhet |
| 7.13 | 11.2.4 | Vedlikehold av utstyr |
| 7.14 | 11.2.7 | Sikker avhending eller gjenbruk av utstyr |
Hvordan ISMS.online hjelper
ISO 27002 implementeringen er enklere med vår trinnvise sjekkliste som guider deg gjennom hele prosessen, fra å definere omfanget av ISMS-en din til risikoidentifikasjon og kontrollimplementering.
Ta kontakt i dag for å bestill en demo.
