Workflow for it-ændringsstyring (SOC 2 CC8.1)

Hvad er workflow for it-ændringsstyring (soc 2 cc8.1)?

Ændringsstyring bliver næsten altid dokumenteret som den lange vej: anmodning, vurdering, møde i ændringsrådet, godkendelse, test, frigivelse. Og så kører hovedparten af de faktiske ændringer ad en anden vej, fordi den lange vej tager fire dage. Det er ikke processen, der er forkert. Det er, at den kun har én vej.

Et diagram, der holder til en walkthrough, har derfor tre spor: standardændringer, der er forhåndsgodkendte og kører uden yderligere godkendelse, normale ændringer, der skal igennem vurdering og godkendelse, og hasteændringer, der må sættes i drift først og godkendes bagefter, inden for en frist og med en dokumenteret begrundelse. Klassificeringen er den første beslutning i forløbet, ikke en note i proceduren.

Den anden ting, auditor tester, er funktionsadskillelsen: kan den, der har udviklet ændringen, selv frigive den til produktion? Det spørgsmål besvares kun af et diagram, hvor godkendelse og idriftsættelse ligger i hver sin bane med hver sin ansvarlige.

Hvad dette flowchart dækker

I denne skabelon

• Ændringsanmodningen: hvem må anmode, hvad der skal beskrives (formål, berørte systemer og tilbagerulningsplan), og hvordan anmodningen registreres
• Klassificering i standardændring, normal ændring og hasteændring: den forgrening, der afgør, hvilken godkendelsesvej ændringen følger
• Konsekvens- og risikovurdering: berørte systemer og data, forventet nedetid, afhængigheder og sikkerhedsmæssig påvirkning
• Godkendelse hos den ændringsansvarlige eller i ændringsrådet (CAB), med en gren for afviste og udsatte ændringer
• Test og godkendelse i testmiljø, herunder kravet om en dokumenteret tilbagerulningsplan, før ændringen frigives
• Idriftsættelse med funktionsadskillelse mellem udvikler og frigiver, efterfølgende verifikation, tilbagerulning ved fejl og en afsluttende evaluering af hasteændringer

Hvornår du skal bruge skabelonen

• I skal igennem en SOC 2-audit, hvor CC8.1-walkthrough'en stiller spørgsmålet: hvordan når en ændring i produktion?
• Hasteændringer bruges som normalvejen, fordi den formelle proces er for langsom, og I vil kunne se hvorfor
• Udviklere frigiver deres egne ændringer, og I skal enten dokumentere eller indføre funktionsadskillelse
• I bruger Jira eller ServiceNow til de enkelte sager, men har ingen styret beskrivelse af selve processen
• Både SOC 2 CC8.1 og ISO 27001 A.8.32 skal dækkes, og I vil have én proces frem for to beskrivelser, der siger noget forskelligt

Dokumenterede kontroller

• CC8.1
• ISO 27001 A.8.32

Sådan fungerer det

1. Start med klassificeringen

   Definér standardændring, normal ændring og hasteændring med konkrete eksempler fra jeres egne systemer. En klassificering, ingen kan anvende uden at spørge, bliver i praksis til 'normal' for alt.

2. Forhåndsgodkend standardændringerne

   Lav en liste over de ændringer, der er lavrisiko og gentagne, og lad dem køre uden enkeltgodkendelse. Det er den eneste måde at få den formelle vej brugt til det, den er beregnet til.

3. Adskil godkendelse fra idriftsættelse

   De to trin skal ligge i hver sin bane med hver sin ansvarlige. Det er det, en SOC 2-walkthrough tester først, og det er svært at dokumentere bagudrettet.

4. Tegn hastevejen med sin frist

   En hasteændring må sættes i drift før godkendelsen, men den efterfølgende godkendelse og evaluering skal have en frist skrevet på noden. Uden en frist er hastevejen en omgåelse.

5. Slut i den efterfølgende evaluering

   Tilføj trinnet, hvor mislykkede og tilbagerullede ændringer gennemgås. Det er der, mønstrene i fejlede idriftsættelser bliver synlige, og det er det trin, der oftest mangler.

Ofte stillede spørgsmål

Hvad kræver SOC 2 CC8.1 om ændringsstyring?

CC8.1 (ændringer, der påvirker systemet) kræver dokumenterede procedurer for at vurdere, godkende, teste og idriftsætte ændringer, samt dokumentation for, at proceduren blev fulgt for de ændringer, der udtages som stikprøver i auditperioden.

Hvordan adskiller QueryChart sig fra et sagssystem som Jira i ændringsstyring?

Sagssystemer holder styr på de enkelte ændringssager; de dokumenterer ikke den styrede, gældende version af selve ændringsprocessen. QueryChart dokumenterer processen (det styrede dokument), så auditor kan se designet, før stikprøverne på driften trækkes i Jira eller ServiceNow.

Hvad er forskellen på en standardændring, en normal ændring og en hasteændring?

En standardændring er lavrisiko, gentagen og forhåndsgodkendt, for eksempel en rutinemæssig certifikatfornyelse. En normal ændring skal igennem konsekvensvurdering og godkendelse, før den må sættes i drift. En hasteændring løser et akut driftsproblem og må idriftsættes først, mod at godkendelsen og evalueringen sker bagefter inden for en fastsat frist. Alle tre spor skal fremgå af diagrammet, ellers beskriver det ikke den proces, der faktisk køres.

Skal alle ændringer igennem et ændringsråd (CAB)?

Nej, og et ændringsråd der behandler alt, bliver en flaskehals, som organisationen begynder at gå uden om. Lad rådet behandle de ændringer, der er tværgående, har kundepåvirkning eller kræver nedetid, og lad de øvrige godkendes af en navngiven ændringsansvarlig. Det afgørende for auditor er, at kriteriet for, hvilke ændringer der skal til rådet, står i den styrede proces, ikke at rådet har set alt.