Workflow for it-ændringsstyring (SOC 2 CC8.1)
SOC 2-klar workflow for it-ændringsstyring: ændringsanmodning, konsekvensvurdering, godkendelse, test, idriftsættelse og efterfølgende evaluering — med en godkendelsesunderskrift på hvert trin.
Sådan fungerer det
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.
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.
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.
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.
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.