Hva er en erklæring om anvendelse?
Enkelt sagt, i sin søken etter å beskytte verdifulle informasjonsressurser og administrere informasjonsbehandlingsfasilitetene, opplyser SoA hvilke ISO 27001-kontroller og retningslinjer som brukes av organisasjonen. Den måler mot vedlegg A-kontrollen satt i ISO 27001-standarden (beskrevet på baksiden av det ISO-standarddokumentet som referansekontrollmål og -kontroller).
Anvendelseserklæringen finnes i 6.1.3 av hovedkravene for ISO 27001, som er en del av den bredere 6.1, fokusert på handlinger for å møte risikoer og muligheter.
SoA er derfor en integrert del av den obligatoriske ISO 27001-dokumentasjonen som må presenteres for en ekstern revisor når ISMS gjennomgår en uavhengig revisjon, for eksempel av et UKAS revisjonssertifiseringsorgan.
Hvem gjelder ISO 27001 for?
ISO 27001 gjelder for alle typer og størrelser av organisasjoner, inkludert offentlige og private selskaper, offentlige enheter og ideelle organisasjoner. Den røde tråden uavhengig av organisasjonsstørrelse, type, geografi eller sektor er at organisasjonen har som mål å demonstrere beste praksis i sin tilnærming til informasjonssikkerhetsstyring. Beste praksis kan selvsagt tolkes annerledes.
ISO-standarden handler om å utvikle et system for håndtering av informasjonssikkerhetsrisiko. Så avhengig av organisasjonens ledelses appetitt på informasjonsrisiko og omfanget av eiendeler for å håndtere risiko rundt, kan kontrollene og retningslinjene som brukes, variere betydelig fra en organisasjon til en annen, men likevel oppfylle ISO 27001-kontrollmålene.
Det som imidlertid er klart er at oppnåelse av ISO 27001-sertifisering gjennom en uavhengig revisjon fra et godkjent ISO-sertifiseringsorgan, vil bety at organisasjonen har nådd et anerkjent nivå av kontroll (beste praksis som standard) for informasjonsmidlene og behandlingsfasiliteter.
ISO 27001-sertifisering gir interesserte parter som sterke kunder og prospekter en høyere grad av tillit enn egenutviklede metoder eller alternative standarder som ikke har samme uavhengige revisjon eller internasjonal anerkjennelse.
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.
Hvorfor er SoA viktig?
Sammen med omfanget av styringssystemet for informasjonssikkerhet, (4.3 i ISO 27001), gir SoA et sammendrag av kontrollene som brukes av organisasjonen. SoA er et kjernekrav for å oppnå ISO-sertifisering av ISMS og vil sammen med omfanget være en av de første tingene som en revisor vil se etter i sitt revisjonsarbeid.
Denne dokumentasjonen må være tilgjengelig for gjennomgang under trinn 1-sertifiseringsrevisjonen, men vil bare bli boret i under trinn 2-revisjonen, når revisor skal teste noen av ISO 27001-kontrollene og sikre at de ikke bare beskriver, men demonstrerer tilstrekkelig. kontrollmålene nås.
Revisor vil gjennomgå informasjonsaktivabeholdningen, vurdere risikoene, deres evaluering og behandlinger, og se etter fysiske bevis på at organisasjonen har implementert kontrollene den har hevdet for å håndtere risikoen på tilfredsstillende måte.
SoA og Scope vil dekke organisasjonens produkter og tjenester, dens informasjonsressurser, prosesseringsfasiliteter, systemer som er i bruk, involverte personer og forretningsprosesser, enten det er en virtuell enpersonsbedrift eller en internasjonal virksomhet med flere nettsteder med tusenvis av ansatte.
Kraftige utdannede kunder med betydelig informasjonsrisiko (f.eks. på grunn av GDPR eller andre kommersielle informasjonsressurser) vil kanskje se omfanget og SoA før de kjøper fra en leverandør, for å sikre at ISO-sertifiseringen faktisk tar for seg områdene av virksomheten som er involvert i deres eiendeler.
Det nytter ikke å ha en ISO-sertifisering med Scope og SoA for et hovedkontor i Storbritannia når selve informasjonsbehandlingsrisikoen finner sted i en offshore-bygning med ressurser utenfor rekkevidde! Det er faktisk en av grunnene til at sertifiseringsorganene nå oppfordrer til «hele organisasjonen» Scopes, noe som selvfølgelig kan bety at det kreves en mye bredere og dypere erklæring om anvendelighet.
Oppsummert viser en godt presentert og lettfattelig SoA forholdet mellom gjeldende og implementerte vedlegg A-kontroller gitt risikoene og informasjonsmidlene i omfang. Det vil gi stor tillit til en revisor eller en annen interessert part at organisasjonen tar informasjonssikkerhetsstyring på alvor, spesielt hvis alt er satt sammen i et helhetlig styringssystem for informasjonssikkerhet.
Hva er vedlegg A ISO 27001?
Vedlegg A til ISO 27001 er en katalog over målene og kontrollene for informasjonssikkerhetskontroll som må vurderes under implementeringen av ISO 27001. Den tekniske termen som brukes for ISO handler om "begrunnelse" av kontrollen, SoA vil vise om vedlegg A-kontrollen er:
- Gjelder og implementert som kontroll nå
- Gjelder, men ikke implementert som en kontroll (f.eks. kan det være en del av en forbedring for fremtiden og fanget opp i 10.2 som en del av en forbedring, eller ledelsen er forberedt på å tolerere risikoen gitt deres andre implementerte kontrollprioriteringer)
- Ikke aktuelt (merk at hvis noe anses som uaktuelt, vil revisor se etter å forstå hvorfor det er så dokumentert at det også bør føres i SoA).
Kontrollene må gjennomgås og jevnlig oppdateres i løpet av den 3-årige ISO-sertifiseringslivssyklusen. Dette er en del av den pågående forbedringsfilosofien for informasjonssikkerhetsadministrasjon som er innebygd i standarden. Gitt den økende veksten i cyberkriminalitet, beveger cybersikkerhet seg også raskt, så alt mindre enn en årlig gjennomgang av kontroller vil potensielt øke organisasjonens trusseleksponering.
Hvor mange kontroller er det i ISO:27001?
ISO 27001:2022 vedlegg A-kontrollene har blitt omstrukturert, konsolidert og modernisert. De 93 kontrollene (ned fra 114 i 2013) er nå kategorisert i fire nøkkelkontrollgrupper, i stedet for de 14 domenene i forrige versjon.
1. Organisasjonskontroller (37 kontroller)
Hva det dekker:
Disse kontrollene fokuserer på styring, risikostyring, operasjonell sikkerhet og overholdelse.
Hvorfor denne kategorien ble slått sammen og oppdatert:
- Forenklet overholdelse og risikostyring – Tidligere var samsvarsrelaterte kontroller spredt over flere domener (f.eks. A.18 – Samsvar og A.6 – Organisering av informasjonssikkerhet).
- Fokus på moderne sikkerhetsstyring – Risikovurdering, trusselintelligens og leverandørsikkerhet er nå forent under denne kategorien for å samsvare med utviklende forretningspraksis.
- Bedre integrasjon med ISO 31000 (Risk Management) – Hjelper organisasjoner å tilpasse risikovurdering og behandlingsmetoder med globale standarder.
Nøkkelkontroller i denne kategorien:
- A.5.7 – Threat Intelligence (ny) – Lagt til for å håndtere trusselovervåking i sanntid og deling av etterretning.
- A.5.21 – Håndtering av informasjonssikkerhetshendelser (sammenslått) – Konsoliderer tidligere hendelsesrespons og loggingskrav.
- A.5.31 – Juridiske, lovpålagte, regulatoriske og kontraktsmessige krav (sammenslått) – Kombinerer A.18.1.1 (Identifisering av gjeldende lovgivning og kontraktsmessige krav) og A.18.1.4 (Personvern og beskyttelse av personlig identifiserbar informasjon) for ett enkelt samsvarsrammeverk.
2. Personkontroller (8 kontroller)
Hva det dekker:
Disse kontrollene adresserer menneskelige sikkerhetsrisikoer, inkludert sikkerhetsbevissthet, opplæring og ansattes ansvar.
Hvorfor denne kategorien ble slått sammen og oppdatert:
- Mennesker er det svakeste leddet – En stor prosentandel av sikkerhetsbrudd oppstår på grunn av menneskelige feil, phishing eller sosial ingeniørkunst.
- Tidligere spredt over flere domener – A.7 (Human Resource Security) og A.12 (Operational Security) inneholdt personrelaterte kontroller, noe som gjorde det vanskeligere å administrere sikkerhetsbevissthet og opplæring helhetlig.
- Passer med treningstrender for cybersecurity Workforce Training – Sikkerhetsbevissthetsprogrammer legger nå vekt på kontinuerlig læring, simulerte phishing-angrep og rollebasert sikkerhetsopplæring.
Nøkkelkontroller i denne kategorien:
- A.6.3 – Informasjonssikkerhetsbevissthet, utdanning og opplæring (sammenslått) – Kombinerer A.7.2.2 (informasjonssikkerhetsbevissthet, utdanning og opplæring) med elementer av A.6.2 (Intern organisasjonsansvar) for et sterkere fokus på kontinuerlig medarbeiderengasjement.
- A.6.1 – Screening (oppdatert) – Styrket til å inkludere bakgrunnssjekker fra entreprenører og tredjeparts risikobetraktninger.
3. Fysiske kontroller (14 kontroller)
Hva det dekker:
Denne delen fokuserer på fysiske sikkerhetstiltak for å beskytte fasiliteter, enheter og datasentre.
Hvorfor denne kategorien ble slått sammen og oppdatert:
- Konsolidering av redundante fysiske sikkerhetskontroller – 2013-versjonen hadde separate kontroller for ulike aspekter av anleggssikkerhet, nå strømlinjeformet til en enkelt kategori.
- Økt fokus på eksternt arbeid og mobilsikkerhet – Med hybridarbeidsmodeller i ferd med å bli normen, tar sikkerhetskontrollene nå tak i sikkerhetsrisikoer for arbeid hjemmefra.
- IoT & Smart Building Sikkerhetshensyn – Fysiske sikkerhetskontroller er oppdatert for å inkludere IoT-sikkerhetsrisikoer og AI-drevet overvåking.
Nøkkelkontroller i denne kategorien:
- A.7.4 – Fysisk sikkerhetsovervåking (ny) – Adresserer sikkerhetskameraer, smarte låser og inntrengningsdeteksjon i sanntid.
- A.7.5 – Arbeid i sikre områder (oppdatert) – inkluderer nå krav til sikker fjernarbeid for å redusere risikoen fra hybride og eksterne arbeidsstyrker.
4. Teknologiske kontroller (34 kontroller)
Hva det dekker:
Denne gruppen fokuserer på IT-infrastruktursikkerhet, skysikkerhet, tilgangskontroll og kryptografi.
Hvorfor denne kategorien ble slått sammen og oppdatert:
- Cyber Threat Landscape har utviklet seg – 2013-versjonen tok ikke fullt ut moderne cybertrusler, inkludert løsepengevare, skybaserte angrep og AI-drevet hacking.
- Rise of Cloud Computing & SaaS Risks – Ny skysikkerhetskontroll (A.5.23 – Information Security for Cloud Services) adresserer multiskymiljøer og modeller for delt ansvar.
- Databeskyttelse og overholdelse av personvern – Nye kontroller som A.8.11 (Datamaskering) og A.8.12 (Datalekkasjeforebygging) samsvarer med GDPR, ISO 27701 og globale personvernforskrifter.
Nøkkelkontroller i denne kategorien:
- A.8.11 – Datamaskering (ny) – Beskytter PII og sensitive data ved å bruke tokeniserings- og anonymiseringsteknikker.
- A.8.12 – Forebygging av datalekkasje (ny) – Implementerer DLP-policyer for å forhindre uautoriserte dataoverføringer.
- A.8.9 – Konfigurasjonsadministrasjon (Ny) – Løser feilkonfigurasjoner i sky- og SaaS-applikasjoner, en hovedårsak til datainnbrudd.
- A.8.23 – Nettfiltrering (ny) – Beskytter brukere mot ondsinnede nettsteder, phishing-forsøk og nedlastinger som er infisert med skadelig programvare.
- A.8.28 – Sikker koding (oppdatert) – Styrker praksis for sikker programvareutviklingslivssyklus (SDLC) for å redusere programvaresårbarheter.
Sammendrag av endringer fra ISO 27001:2013
| ISO 27001:2013 (114 kontroller) | ISO 27001:2022 (93 kontroller) | Årsak til endring |
|---|---|---|
| 14 kontrolldomener | 4 hovedkontrollgrupper | Forenkler administrasjonen og tilpasser seg moderne cybersikkerhetsrammer |
| Redundante overholdelseskontroller | Samlet til A.5.31 | Kombinerer juridiske, regulatoriske og kontraktsmessige krav |
| Separate HR-, Awareness- og Incident-kontroller | Konsolidert under People Controls | Sterkere fokus på sikkerhetskultur og medarbeiderbevissthet |
| Manglet moderne cybersikkerhetstrusler | Lagt til trusselintelligens, skysikkerhet og DLP | Adresser løsepengevare, skyrisikoer og moderne angrepsvektorer |
ISO 27001:2022 Kontrollattributter og NIST CSF-justering
ISO 27001:2022 introdusert kontroll attributter for å forbedre klassifiseringen og forbedre tilpasningen til cybersikkerhetsrammer som NIST CSF. Disse attributtene hjelper organisasjoner med å kartlegge kontrollene sine til bredere sikkerhetsdomener, noe som gjør det enklere å implementere samsvar på tvers av rammeverk.
Kontrollattributter i ISO 27001:2022
| Egenskap | Tekniske beskrivelser | NIST CSF Mapping |
|---|---|---|
| Kontrolltype | Definerer om kontrollen er forebyggende, detektiv eller korrigerende | Identifiser, Beskytt, Oppdag, Svar, Gjenopprett |
| Informasjonssikkerhetsegenskaper | Spesifiserer hvilken CIA-triadeprinsippet (Konfidensialitet, Integritet, Tilgjengelighet) kontrollen beskytter | Beskytt, oppdage, gjenopprett |
| Konsepter for cybersikkerhet | Kartlegger kontrollen til cybersikkerhetskonsepter som styring, identitetshåndtering, trusseldeteksjon, datasikkerhet, resiliens | Alle NIST CSF-funksjoner |
| Operasjonelle evner | Definerer sikkerhetsområdet det støtter, for eksempel overvåking, logging, hendelsesrespons, tilgangskontroll | Beskytt, oppdage, svar |
| Sikkerhetsdomener | Lenker til bredere sikkerhetsområder som f.eks nettverkssikkerhet, databeskyttelse, risikostyring, skysikkerhet | Identifiser, Beskytt, Oppdag |
ISO 27001:2022 Kontrollmapping til NIST CSF
| ISO 27001:2022 Kontroll | Kontrolltype | CIA eiendom | Cybersikkerhetskonsept | Operasjonell evne | Sikkerhetsdomene | NIST CSF-funksjon |
|---|---|---|---|---|---|---|
| A.5.7 – Trusseletterretning | Forebyggende | Konfidensialitet, integritet | Trusselovervåking og deteksjon | Logging, Analyse | Risk Management | Identifiser, oppdage |
| A.8.11 – Datamaskering | Forebyggende | Konfidensialitet | Databeskyttelse, personvern | Data Security | Dataledelse | Beskytt |
| A.8.12 – Forebygging av datalekkasje | Forebyggende, detektiv | Konfidensialitet | Endpoint Security, Network Security | Overvåking, forebygging | Sky- og endepunktsikkerhet | Beskytt, oppdage |
| A.8.9 – Konfigurasjonsadministrasjon | Forebyggende | Integritet, tilgjengelighet | Sikkerhetsherding | System vedlikehold | Nettverkssikkerhet | Beskytt |
Fordeler med å bruke kontrollattributter
- Forbedret styring og overholdelse – Gjør det enklere å rettferdiggjøre kontroller i revisjoner for ISO 27001, NIST og SOC 2.
- Forbedret kryssrammejustering – Hjelper med å kartlegge kontroller på tvers av NIST CSF, CIS 18 og ISO 27701.
- Sterkere risikobasert tilnærming – Organisasjoner kan prioritere kontroller basert på risikofaktorer og sikkerhetsmål.
- Cloud & Remote Work Security – Kontrollattributter fremhever nye risikoer innen cloud computing, hybrid arbeidsstyrke og forsyningskjedesikkerhet.
Frigjør deg fra et fjell av regneark
Bygg inn, utvid og skaler samsvarsstyringen din uten rot. IO gir deg robustheten og selvtilliten til å vokse sikkert.
Hvilke kontroller bør jeg inkludere?
Anvendelseserklæringen er hovedkoblingen mellom risikovurderingen og behandlingsarbeidet ditt for informasjonssikkerhet, og viser «hvor» du har valgt å implementere informasjonssikkerhetskontroller fra de 93 kontrollmålene (en god SoA vil også kunne gå i dybden for å vise «hvordan» de har blitt implementert).
Mens vedlegg A-kontrollene gir en nyttig sjekkliste for vurdering, kan det å bare implementere alle 93 kontrollene fra "nedenfra og opp" være dyrt og gå glipp av de grunnleggende målene med standarden. Dessverre vil noen informasjonssikkerhetskonsulenter og -leverandører som selger "fullstendige ISO 27001 dokumentasjonsverktøysett" gå inn for denne tilnærmingen, men det er feil måte å administrere informasjonssikkerhet på.
Det er en grunn til at kjernekravene i ISO 27001 fra 4.1-10.2 er der. De hjelper organisasjonen med den forretnings- og strategiledede tilnærmingen der du ser ovenfra og ned. Etter å ha vurdert problemene, interessepartene, omfanget og informasjonsmidlene, kan organisasjonen identifisere risikoene, deretter evaluere dem og vurdere behandlinger for disse risikoene.
Risikoen rundt den verdifulle informasjonen og behandlingsfasiliteter, enheter, involverte personer osv. bør vurderes med informasjonens konfidensialitet, integritet og tilgjengelighet (CIA) i tankene.
Denne sammenbruddet av CIA er også et viktig aspekt for revisor å forstå og demonstrere at organisasjonen har mer helhetlig vurdert risikoen. Avgjørende betyr det også at SoA har blitt utviklet med den mer omfattende tilnærmingen, snarere enn bare én del, f.eks. bare vurdert risikoen for tap av informasjon fra et brudd.
Selv om organisasjonen vil vurdere risikoen fra sin virksomhet som trukket opp ovenfra, er det verdt å nevne at et av kontrollområdene i vedlegg A som alltid vil være gjeldende er «Kontroll: A.5.31 – Lovlige, lovpålagte, regulatoriske og kontraktsmessige krav. Dette vil bety at du også vurderer kravene i relevante lover, forskrifter og kontraktskrav. Det blir mye mer fremtredende på grunn av EUs GDPR for de som behandler EU-borgerinformasjon og i økende grad over hele verden også med andre personvernstandarder som POPI i Sør-Afrika, LGPD i Brasil og CCPA i California.
For å forstå forventningene til personvernregelverket, tilsier det også effektivt at mange av ISO 27001-kontrollene kreves, enten du tror de er det eller ikke. Så en smart revisor vil forvente en forståelse av gjeldende lovgivning som påvirker organisasjonen din, og hvordan det også informerer ditt valg av gjeldende kontroller i SoA-begrunnelsen.
Noen informasjonssikkerhetsrisikoer kan selvsagt avsluttes helt, overføres til en annen part, behandles eller tolereres. Alle disse vedlegg A-kontrollene hjelper deg deretter å vurdere og, der det er hensiktsmessig, implementere overføringen, behandle eller tolerere filosofien rundt risikoene. SoA viser deretter hvilke sikkerhetstiltak fra vedlegg A-kontrollene du bruker og hvordan du har implementert dem, dvs. dine retningslinjer og prosedyrer.
Vedlegg A-kontrollmålene og kontrollene som er oppført i ISO 27001-standarden er ikke foreskrivende, men må vurderes, og at begrunnelse for anvendelighet er avgjørende for en uavhengig sertifisering fra et ISO-sertifiseringsorgan.
ISO 27002 og erklæringen om anvendelighet
Enten uavhengig sertifisering er et mål eller kanskje bare overholdelse, kombinert med den komplementære ISO 27002-veiledningen, er vedlegg A-kontrollene et positivt grunnlag å bygge på for enhver organisasjon som ønsker å forbedre sin informasjonssikkerhetsstilling og gjøre forretninger sikrere.
ISO 27002, er tilleggsstandarden til ISO 27001, gir en anbefaling og nyttig disposisjon for informasjonssikkerhetskontroller og gir dermed en meget god katalog over kontrollmål og kontroller for behandling av risikoer samt veiledning om hvordan disse implementeres.
Hvilke sikkerhetstiltak (vedlegg A kontroller) du implementerer for å håndtere disse risikoene vil faktisk avhenge av organisasjonen din, dens risikovilje og omfanget samt gjeldende lovgivning. Men uansett hva det er, må det presenteres i Statement of Applicability hvis du ønsker å oppnå en ISO 27001-sertifisering!
Hvilken informasjon må inkluderes i SoA?
Så la oss oppsummere hvilken informasjon som minimum må inkluderes for SoA.
- En liste over de 93 nnex A-kontrollene
- Om kontrollen er iverksatt eller ikke
- Begrunnelse for inkludering eller ekskludering
- En kort beskrivelse eller hvordan hver gjeldende kontroll implementeres, med referanse til policyen og kontrollen som beskriver den i riktig detalj
Som nevnt ovenfor er SoA et vindu inn i organisasjonens ISMS. Hvis du ikke er i stand til å vise hvordan vinduet åpner seg i dybden og sammenhengen til styringssystemet for informasjonssikkerhet, kan det skape problemer. Se for deg situasjonen når revisor dukker opp og regnearket som viser 93-kontrollene er godt utdatert med de faktiske ledelseskontrollene på plass.
En av de vanligste årsakene til å mislykkes i en ISO 27001-revisjon er fordi revisor ikke er i stand til å trekke tillit til administrasjonen av ISMS og dokumentasjonen er dårlig administrert eller mangler. Å ha et frittstående SoA 'dokument' i stedet for integrert og automatisert dokumentasjon av en SoA øker denne risikoen.
Hvordan lager du erklæringen om anvendelse?
Så lenge SoA har riktig informasjon, er nøyaktig og oppdatert, kan du lage SoA fra papir, regneark, dokumenter eller profesjonelle systemer som automatiserer den som en del av deres bredere GRC (Governance, Regulation & Compliance)-evne .
I en ideell verden vil din SoA neppe endre seg (ikke minst fordi sertifiseringsorganer kan ta betalt for versjonsendringer av SoA). Imidlertid bør det som sitter under SoA, dvs. det bankende hjertet til selve ISMS, være dynamisk som en levende pustende representasjon av ditt utviklende informasjonssikkerhetslandskap.
SoA må gjennomgås når retningslinjene og kontrollene dine gjennomgås (minst årlig), så det vil fortsatt ha fordel av å være en effektiv prosess gitt de 114 kontrollene for vurdering.
Å slå opp et regneark med kontrollene som en sjekkliste er et stykke kake og ganske raskt å gjøre. Men å gjøre det med tillit til at alt tidligere informasjonssikkerhetsplanlegging og implementeringsarbeid rundt eiendelene, risikoene og kontrollene har blitt gjort i riktig rekkefølge og uttrykt som oppsummeringen SoA er ikke fullt så enkelt. En revisor vil ønske å se hva som ligger under den enkle overlinjen på 114 rader i et regneark.
I gamle dager betydde det virkelig mye arbeid å presentere SoA som et 200 sider omfattende dokument, spesielt for å holde det oppdatert etter hvert som retningslinjene og kontrollene utviklet seg. Det er nå mye bedre og enklere måter å automatisere SoA og dra nytte av det harde arbeidet som allerede er gjort i andre deler av ISMS.
Hvordan spare tid når du skriver en erklæring om anvendelse
SoA tar vanligvis lang tid for en organisasjon å sette sammen på grunn av det som informerer den. Hvis vi tenker på trinnene som er involvert i opprettelsen, og arbeidet som trengs for det, er det ikke rart:
- Vurder problemene, interesserte parter og omfanget av ISMS
- Identifiser informasjonsmidlene og behandlingsfasiliteter og enheter som er i fare
- Evaluer og vurder risikoene knyttet til sikkerheten til informasjonen ved å bruke konfidensialitet, integritet og tilgjengelighet
- Vurder disse risikoene og avgjør deretter hvilke av de 114 vedlegg A-kontrollene som er nødvendige
- Forstå og evaluere gjeldende lovgivning (og eventuelle sentrale kontraktsforpliktelser fra sterke kunder) for å fremheve andre kontrollområder
- Bestem deg for hvordan du implementerer kontrollen når det gjelder policy, prosedyre, personer, teknologi etc
- Deretter oppretter du selve SoA-dokumentet med disse begrunnelsene om anvendelighet klare
- Ideelt sett kobler du til kontrolldetaljene, risikoene og eiendelene for å vise at ISMS fungerer
- Og administrer det på fortløpende basis. SoA er en liten, men veldig viktig del av et svært omfattende ISMS. Godt gjort vil det sette organisasjonen opp for revisjonssuksess og tillitsbygging for smarte kunder og andre interessenter. Gjøres det dårlig, vil det nesten helt sikkert forstyrre og forsinke tiden til sertifisering og kan bety tap av virksomhet eller fremtidig mulighet fra manglende oppnåelse eller opprettholdelse av sertifisering.
Få fart på SoA-prosessen med ISMS.online
ISMS.online er et omfattende styringssystem for informasjonssikkerhet som blant mange andre ting forenkler administrasjonen og administrasjonen av dine informasjonsressurser, risikoer, retningslinjer og kontroller, alt på ett sted.
Det betyr også at opprettelsen av SoA kan automatiseres og presenteres enkelt og effektivt. Derfor, i tillegg til andre fordeler som å koste mindre tid for å oppnå ISO 27001-suksess, fremskynder det ISO-sertifiseringsreisen også.
Fokuser energien din på å drive virksomheten din slik du vil, og bruk tid på det du trenger å oppnå for å lykkes, og bekymre deg mindre om hvordan du gjør det. ISMS.online gjør det så enkelt å få arbeidet gjort, inkludert SoA til en brøkdel av kostnadene og tiden for alternativer.
