{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/change-management","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/change-management/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/change-management/"},"term":{"en":"Change management","da":"Change management"},"aka":{"en":["change control"],"da":["ændringsstyring","ændringshåndtering"]},"domain":["security"],"cluster":"controls","layer":"governance","status":"current","summary":{"en":"A controlled process to plan, approve, record and check every change made to IT systems.","da":"En styret proces for at planlægge, godkende, registrere og efterprøve alle ændringer i IT-systemer."},"body":{"formal":{"en":"A defined process in which each change to systems is described, judged for risk, approved by the right person, carried out at an agreed time with a way back, and recorded so it can be traced later.","da":"En fastlagt proces, hvor hver ændring i systemerne beskrives, risikovurderes, godkendes af den rette person, gennemføres på et aftalt tidspunkt med en vej tilbage og registreres, så den kan spores bagefter."},"plain":{"en":"Like a building project where no wall comes down until the plans are approved, the neighbours are told, and there is a way to put it back up.","da":"Som et byggeprojekt, hvor ingen væg rives ned, før tegningerne er godkendt, naboerne er orienteret, og der er en plan for at sætte den op igen."},"inPractice":{"en":"At a regional hospital, a network technician requests a new firewall rule on a form; a colleague checks it, Tuesday's change meeting approves it, and it goes live on Thursday night with a note on how to undo it.","da":"På et regionshospital bestiller en netværkstekniker en ny firewall-regel via en formular; en kollega tjekker den, tirsdagens ændringsmøde godkender den, og den sættes i drift torsdag aften med en note om, hvordan den rulles tilbage."},"whyItMatters":{"en":"Many outages and security holes come from well-meant changes that nobody checked; a clear process catches mistakes early and shows who changed what if something breaks.","da":"Mange nedbrud og sikkerhedshuller skyldes velmente ændringer, som ingen har tjekket; en klar proces fanger fejl tidligt og viser, hvem der ændrede hvad, hvis noget går galt."}},"deepDive":{"en":"Most change processes descend from ITIL, which classifies changes into three types. Standard changes are low-risk, pre-authorised and repeatable (adding a user to a group, a routine certificate renewal) and follow a documented procedure without individual approval. Normal changes are assessed and authorised case by case, by a change authority whose level scales with risk - a peer, a team lead or a change advisory board (CAB). Emergency changes are expedited to fix an incident or close an actively exploited hole, with reduced up-front approval and mandatory retrospective review. ITIL 4 renamed the practice change enablement and deliberately decoupled authority from the CAB meeting, recognising that a weekly board is a bottleneck for high-frequency delivery.\n\nA well-formed change record contains the scope and affected configuration items (which is why the process depends on an asset inventory or CMDB), a risk and impact assessment, a test result, an implementation window, a tested backout plan, and post-implementation verification. The security value lies in three properties: segregation of duties (the requester is not the sole approver), traceability (every production difference maps to an authorised record) and detection of unauthorised change, typically by comparing configuration baselines, file integrity monitoring or infrastructure-as-code drift detection against approved state.\n\nIn DevOps and GitOps environments the same control objectives are met by the pipeline rather than by a meeting: a pull request with mandatory peer review and branch protection is the change request and approval, automated tests are the impact assessment, the merge commit is the audit trail, and progressive delivery with automated rollback is the backout plan. The research published in Accelerate (Forsgren, Humble and Kim, 2018) found that approval by an external body such as a CAB was negatively correlated with delivery performance and not correlated with lower change failure rates - an argument for lightweight, peer-based approval backed by automation, not for dropping control.\n\nNormative references: ISO/IEC 27002:2022 control 8.32 (change management), closely tied to 8.9 (configuration management); ISO/IEC 20000-1 for service management; and, not to be confused with operational change, ISO/IEC 27001:2022 clause 6.3, which requires changes to the ISMS itself to be planned. Auditors test it by sampling production changes from system logs and tracing each back to an approved record; unrecorded changes, self-approved changes and emergency changes that never got their retrospective review are the classic findings. Many outages attributed to \"configuration errors\" - including cloud misconfigurations that expose storage publicly - are change-management failures in this sense.","da":"De fleste ændringsprocesser stammer fra ITIL, som inddeler ændringer i tre typer. Standardændringer er lavrisiko, forhåndsgodkendte og gentagelige (at tilføje en bruger til en gruppe, en rutinemæssig fornyelse af et certifikat) og følger en dokumenteret procedure uden individuel godkendelse. Normale ændringer vurderes og godkendes enkeltvis af en ændringsmyndighed, hvis niveau følger risikoen - en kollega, en teamleder eller et change advisory board (CAB). Nødændringer fremskyndes for at løse en hændelse eller lukke et hul, der aktivt udnyttes, med reduceret forhåndsgodkendelse og obligatorisk efterfølgende gennemgang. ITIL 4 omdøbte praksissen til change enablement og frakoblede bevidst godkendelsesmyndigheden fra CAB-mødet, fordi et ugentligt møde er en flaskehals ved hyppige leverancer.\n\nEn velformet ændringsanmodning indeholder omfang og berørte konfigurationselementer (derfor afhænger processen af en aktivfortegnelse eller CMDB), en risiko- og konsekvensvurdering, et testresultat, et implementeringsvindue, en testet rollback-plan og efterfølgende verifikation. Sikkerhedsværdien ligger i tre egenskaber: funktionsadskillelse (den, der anmoder, er ikke eneste godkender), sporbarhed (hver forskel i produktion kan føres tilbage til en godkendt registrering) og opdagelse af uautoriserede ændringer, typisk ved at sammenligne konfigurationsbaselines, file integrity monitoring eller drift-detektion i infrastructure-as-code med den godkendte tilstand.\n\nI DevOps- og GitOps-miljøer opfyldes de samme kontrolmål af pipelinen i stedet for et møde: en pull request med obligatorisk peer review og branch protection er ændringsanmodningen og godkendelsen, automatiske tests er konsekvensvurderingen, merge-committen er revisionssporet, og progressiv udrulning med automatisk rollback er tilbagerulningsplanen. Forskningen i Accelerate (Forsgren, Humble og Kim, 2018) fandt, at godkendelse fra et eksternt organ som et CAB var negativt korreleret med leveranceevne og ikke hang sammen med færre fejlslagne ændringer - et argument for let, kollegabaseret godkendelse understøttet af automatisering, ikke for at droppe kontrollen.\n\nNormative referencer: ISO/IEC 27002:2022 kontrol 8.32 (ændringsstyring), tæt knyttet til 8.9 (konfigurationsstyring); ISO/IEC 20000-1 for servicestyring; og - ikke at forveksle med driftsændringer - ISO/IEC 27001:2022 afsnit 6.3, der kræver, at ændringer af selve ledelsessystemet (ISMS) planlægges. Revisorer tester kontrollen ved at trække et udsnit af produktionsændringer fra systemlogs og spore hver enkelt tilbage til en godkendt registrering; uregistrerede ændringer, selvgodkendte ændringer og nødændringer, der aldrig fik deres efterfølgende gennemgang, er de klassiske fund. Mange nedbrud, der tilskrives \"konfigurationsfejl\" - også fejlkonfigurationer i cloud, der gør lagring offentligt tilgængelig - er i denne forstand fejl i ændringsstyringen."},"edges":[{"type":"requires","to":"security/asset-inventory","confidence":"high","strength":"normal"},{"type":"kind-of","to":"security/control","confidence":"high","strength":"normal"},{"type":"mitigates","to":"platform/cloud-misconfiguration","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/patch-management","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/devsecops","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/gitops","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/version-control","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/it-operations","confidence":"high","strength":"normal"}],"depth":1,"sources":[{"title":"Cyber Security Fast Track - Ordliste","tier":"course-material"},{"title":"ISO/IEC 27002:2022 - Control 8.32 Change management","tier":"standard","publisher":"ISO/IEC"}],"draft":true}