Update documentation files with clearer descriptions and clarifications

docs/01_planlegge/03_business_continuity.md

@@ -18,7 +18,7 @@ Her er det viktig å ha et forhold til
 ## Kundens forventninger 
 Har vi definert en Service Level Agreement (SLA) med kunden som legger føringer på oppetid, tilgjengelighet og liknende, eller har kunden implisitte forventninger til dette? 
 
-Dette må avklares slik at en kjenner konsekvensene nedetid vil få. I mange prosjekter benyttes det skykomponenter der en ikke har kontroll over alle variabler selv. Derfor er det viktig å tidlig i prosjektet gå opp de faktiske behovene med kunden. Vi kan sikre redundans på alle fronter dersom kunden ønsker det, men det koster da deretter. 
+Dette må avklares slik at en kjenner konsekvensene nedetid vil få. I mange prosjekter benyttes det skykomponenter der en ikke har kontroll over alle variabler selv. Derfor er det viktig å tidlig i prosjektet avklare de faktiske behovene med kunden. Vi kan sikre redundans på alle fronter dersom kunden ønsker det, men det koster da deretter. 
 
 Dersom en går opp dette i forkant er det lettere å henvise til dokumentasjon og avtaler når løsningen blir utilgjengelig for å unngå dårlig stemning. 
 

docs/01_planlegge/introduction.md

@@ -3,10 +3,10 @@
 <div className="row category-into">
     <div className="column">
         <p>
-            Det viktigste vi kan gjøre før vi skriver en eneste kodelinje er å gå opp ansvarsfordelingen mellom oss og kunden, samt klassifiseringen av løsning og data: Hvilke krav stiller kunden og hvilke krav kommer fra lovverk eller andre parter? Kompetanse innenfor applikasjonssikkerhet (AppSec) bør være på banen allerede i denne fasen for å sikre at en ivaretar krav og forventninger til sikkerhet.
+            Det viktigste vi kan gjøre før vi skriver en eneste kodelinje er å blie enige om ansvarsfordelingen mellom oss og kunden, samt klassifiseringen av løsning og data: Hvilke krav stiller kunden og hvilke krav kommer fra lovverk eller andre parter? Kompetanse innenfor applikasjonssikkerhet (AppSec) bør være på banen allerede i denne fasen for å sikre at en ivaretar krav og forventninger til sikkerhet.
         </p>
         <p>
-            Vi må også gå opp hva vi gjør ~~dersom~~når det oppstår en sikkerhetshendelse - hvilke krav står vi ovenfor, hva må til for at disaster recovery, backup og liknende skal lykkes, og hva vil konsekvensene av nedetid være for kunden? 
+            Vi må også vite hva vi gjør ~~dersom~~når det oppstår en sikkerhetshendelse - hvilke krav står vi ovenfor, hva må til for at disaster recovery, backup og liknende skal lykkes, og hva vil konsekvensene av nedetid være for kunden? 
         </p>
     </div>
     <div className="column">

docs/04_deploye/04_pentesting.md

@@ -27,7 +27,7 @@ Som en del av planleggingen er det viktig å sjekke opp med kunden hvilke rutine
 I noen tilfeller er det ønskelig med en pentest uten at dette varsles, da en ønsker å se om en slik test fanges opp - Husk på at en pentest i praksis er et angrep.
 
 ## Når gjennomfører jeg en pentest, og hva gjør vi når den pågår? 
-I en perfekt verden bør man gjennomføre en pentester ved alle større endringer, men dette er ikke aktuelt med unntak av hos noen få aktører med særskilte krav. Her vil hver enkelt kunde ha ulike krav og forventninger, så det er viktig å gå opp retningslinjene på dette _før_ en ser for seg å gjennomføre testen.  
+I en perfekt verden bør man gjennomføre en pentester ved alle større endringer, men dette er ikke aktuelt med unntak av hos noen få aktører med særskilte krav. Her vil hver enkelt kunde ha ulike krav og forventninger, så det er viktig å ha retningslinjer på dette _før_ en ser for seg å gjennomføre testen.  
 
 Dersom testen er varslet i forkant er det en kjempegod anledning til å følge med på logger og annen monitorering for å se om du ser noe unormalt. Dersom du i etterkant kan korrelere denne informasjonen med testene som blir rapportert har du en god mulighet til å lage automatiske varslingsrutiner som fanger opp avvik fra normalen. 
 

docs/05_forvalte/02_audit.md

@@ -5,10 +5,10 @@ title: Audit/revisjon
 
 # Audit eller revisjon av prosjekt eller leveranse
 :::tip Kort oppsummert
-Uavhengig av egne kontroller kommer vi noen ganger i situasjoner der kunde eller mottaker ønsker å gå opp kvalitet og rutiner rundt det som leveres. Sikkerhet og kvalitet i en løsning krever andre tiltak enn det funksjonelle, som typisk er lettere å verifisere opp mot kundens krav. 
+Uavhengig av egne kontroller kommer vi noen ganger i situasjoner der kunde eller mottaker ønsker å gjennomgå kvalitet og rutiner rundt det som leveres. Sikkerhet og kvalitet i en løsning krever andre tiltak enn det funksjonelle, som typisk er lettere å verifisere opp mot kundens krav. 
 :::
 
-Det er langt fra alle leveranser som er aktuelle for revisjon eller audit fra kundens side, dette vil typisk gjelde leveranser der Bouvet har tatt styring og kunden i større grad mottar en løsning uten at de er tungt involvert i driften av prosjektet. En revisjon er verktøy kunden kan benytte for å sikre at Bouvet har gjort jobben som avtalt, der kunden har mulighet til å gå opp våre rutiner og arbeidsprosesser for å sikre at vi har levert som vi skal. 
+Det er langt fra alle leveranser som er aktuelle for revisjon eller audit fra kundens side, dette vil typisk gjelde leveranser der Bouvet har tatt styring og kunden i større grad mottar en løsning uten at de er tungt involvert i driften av prosjektet. En revisjon er verktøy kunden kan benytte for å sikre at Bouvet har gjort jobben som avtalt, der kunden har mulighet til å gjennomgå våre rutiner og arbeidsprosesser for å sikre at vi har levert som vi skal. 
 
 En slik revisjon vil være avklart i kontrakten vi jobber mot, men det er langt ifra alle kunder som benytter seg av denne muligheten. I mange tilfeller vil det være mest aktuelt med en revisjon når prosjektet leveres eller på et tidspunkt etter levering når det er i drift. Målet vil da være å verifisere at kravene til prosjektet er oppfylt, og at det forvaltes og driftes på en måte som er i samsvar med det kunden forventer og krever.
 

docs/05_forvalte/06_incident_response.md

@@ -20,7 +20,7 @@ Dette er dekket i flere artikler under "[Planlegge](../01_planlegge/introduction
 # Når hendelsen inntreffer
 Hendelser kan ta mange ulike former. En hendelse kan være svakheter eller sårbarheter som oppdages i en applikasjon, avhengigheter eller kjøremiljø, men det kan også være angrep - både åpenbare eller mer i det skjulte. 
 
-Dersom dere oppdager, eller har grunn til å tro at en løsning er under angrep må dette varsles til kunden umiddelbart. Det er ikke alltid tilfelle at løsningen som angripes er den som er målet, i mange tilfeller er en løsning bare et springbrett videre til en annen. Derfor er det også viktig å vite hvilke tilganger og nettverksåpninger denne har til andre løsninger, slik at kundens IT-organisasjon kan gå opp disse for å se etter tegn på angrep der. 
+Dersom dere oppdager, eller har grunn til å tro at en løsning er under angrep må dette varsles til kunden umiddelbart. Det er ikke alltid tilfelle at løsningen som angripes er den som er målet, i mange tilfeller er en løsning bare et springbrett videre til en annen. Derfor er det også viktig å vite hvilke tilganger og nettverksåpninger denne har til andre løsninger, slik at kundens IT-organisasjon kan analysere disse for å se etter tegn på angrep der. 
 
 Om dere kommer over tegn på at en løsning har blitt angrepet eller brukt til et angrep er det også viktig å si ifra, slik at kunden kan sikre informasjon og bevis på dette for videre etterforskning.