{"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/security-policy","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/security-policy/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/security-policy/"},"term":{"en":"Security policy","da":"Sikkerhedspolitik"},"aka":{"en":["information security policy"],"da":["informationssikkerhedspolitik"]},"domain":["security"],"cluster":"fundamentals","layer":"governance","status":"current","summary":{"en":"A document that sets out an organisation's goals, responsibilities and principles for information security.","da":"Et dokument, der fastlægger organisationens mål, ansvar og principper for informationssikkerhed."},"body":{"formal":{"en":"A leadership-approved statement of the organisation's intent for information security - its goals, who is responsible for what, and the rules everyone must follow. It is reviewed at set times and backed by more detailed rules for specific topics.","da":"En ledelsesgodkendt erklæring om organisationens hensigt med informationssikkerheden - dens mål, hvem der har ansvar for hvad, og de regler, alle skal følge. Den gennemgås med faste mellemrum og bakkes op af mere detaljerede regler for bestemte emner."},"plain":{"en":"Like the house rules on a fridge - short, agreed by the grown-ups, and meant to settle arguments before they start.","da":"Som husets regler på køleskabet - korte, vedtaget af de voksne og beregnet til at afgøre diskussioner, før de opstår."},"inPractice":{"en":"A new case worker at a Danish municipality reads and accepts the security policy on day one; among other things it says that work files may only be stored in approved places, never on a private cloud account.","da":"En ny sagsbehandler i en kommune læser og accepterer sikkerhedspolitikken første dag; den siger blandt andet, at arbejdsfiler kun må gemmes på godkendte steder og aldrig på en privat cloudkonto."},"whyItMatters":{"en":"It turns leadership's intent into something written and shared, which every later rule, control and audit can point back to.","da":"Den gør ledelsens hensigt til noget skriftligt og fælles, som alle senere regler, kontroller og audits kan henvise tilbage til."}},"deepDive":{"en":"A security policy sits at the top of a documentation hierarchy that security practitioners distinguish carefully: policies state intent and mandate (\"what and why\", approved by top management and relatively stable), standards make requirements concrete and mandatory (\"passwords must meet these rules\"), procedures give step-by-step instructions (\"how\"), and guidelines offer recommended but non-binding practice. Conflating these is a common failure - a \"policy\" full of technical specifics becomes obsolete quickly and needs board re-approval for trivial changes, while genuine mandate gets buried. In an ISO/IEC 27001 information security management system (ISMS), the top-level information security policy is required by clause 5.2, must be approved by top management, communicated and made available to interested parties, and reviewed at planned intervals; ISO/IEC 27002:2022 Control 5.1 (Policies for information security) expects it to be supported by topic-specific policies (access control, acceptable use, cryptography, incident management, and so on).\n\nThe policy set is the governance instrument that turns leadership intent into an auditable baseline. Every subordinate control, standard and audit criterion should trace back to a policy statement, which is what lets an auditor test not just whether a control exists but whether it implements a documented decision. Regulatory frameworks make top-management ownership explicit: NIS2 Article 20 places accountability for cybersecurity risk-management measures on management bodies and requires them to be trained, so the policy is no longer something IT owns alone. The document typically defines scope, roles and responsibilities (often against a RACI matrix), the risk-appetite statement it enforces, compliance obligations, enforcement and consequences for violations, and its own review cadence and owner.\n\nEffectiveness depends on lifecycle discipline more than on wording. A policy that is written, approved and then never revisited becomes a \"paper policy\" - present for audit but disconnected from practice, which is arguably worse than none because it creates false assurance and, after an incident, evidence of a known-but-ignored control. Good practice ties each policy to a named owner, a review date (commonly annual or on significant change), version control, a record of employee acknowledgement, and measurable compliance so that exceptions are formally requested, risk-assessed and time-boxed rather than quietly tolerated.\n\nTwo misconceptions recur. First, that more policy is better: an over-long, unreadable policy set reduces compliance because staff cannot find or absorb it, so brevity and clarity are security properties. Second, that the policy itself provides protection; it is an administrative control that shapes behaviour and enables enforcement, but it mitigates risk only when backed by technical controls, training and monitoring that make the stated rules real. The security policy is thus the connective tissue between governance and the operational controls documented elsewhere, not a substitute for them.","da":"En sikkerhedspolitik ligger øverst i et dokumenthierarki, som sikkerhedsfolk skelner nøje i: politikker angiver hensigt og mandat (\"hvad og hvorfor\", godkendt af den øverste ledelse og forholdsvis stabile), standarder gør krav konkrete og obligatoriske (\"adgangskoder skal opfylde disse regler\"), procedurer giver trinvise anvisninger (\"hvordan\"), og retningslinjer tilbyder anbefalet, men ikke-bindende praksis. At blande dem sammen er en almindelig fejl - en \"politik\" fuld af tekniske detaljer bliver hurtigt forældet og kræver fornyet ledelsesgodkendelse ved trivielle ændringer, mens det egentlige mandat begraves. I et ISO/IEC 27001-ledelsessystem for informationssikkerhed (ISMS) kræves den øverste informationssikkerhedspolitik af clause 5.2: den skal godkendes af den øverste ledelse, kommunikeres og gøres tilgængelig for interessenter samt gennemgås med planlagte mellemrum; ISO/IEC 27002:2022 Control 5.1 (Policies for information security) forventer, at den understøttes af emnespecifikke politikker (adgangskontrol, acceptabel brug, kryptografi, hændelseshåndtering og så videre).\n\nPolitiksættet er det governance-instrument, der omsætter ledelsens hensigt til en auditerbar baseline. Enhver underordnet kontrol, standard og revisionskriterium bør kunne føres tilbage til et politikudsagn, og det er netop dét, der lader en auditor teste ikke blot, om en kontrol findes, men om den implementerer en dokumenteret beslutning. Regelsæt gør ledelsens ejerskab eksplicit: NIS2 artikel 20 placerer ansvaret for foranstaltninger til styring af cybersikkerhedsrisici hos ledelsesorganerne og kræver, at de uddannes, så politikken ikke længere er noget, IT ejer alene. Dokumentet definerer typisk anvendelsesområde, roller og ansvar (ofte mod en RACI-matrix), den risikoappetit, det håndhæver, compliance-forpligtelser, håndhævelse og konsekvenser ved overtrædelser samt sin egen revisionskadence og ejer.\n\nEffektivitet afhænger mere af livscyklusdisciplin end af ordlyd. En politik, der skrives, godkendes og derefter aldrig genbesøges, bliver en \"papirpolitik\" - til stede ved audit, men afkoblet fra praksis, hvilket vel er værre end ingen, fordi den skaber falsk tryghed og efter en hændelse udgør bevis for en kendt, men ignoreret kontrol. God praksis knytter hver politik til en navngiven ejer, en revisionsdato (ofte årlig eller ved væsentlig ændring), versionsstyring, en registrering af medarbejdernes accept og målbar efterlevelse, så undtagelser formelt anmodes om, risikovurderes og tidsbegrænses frem for at blive stiltiende tolereret.\n\nTo misforståelser går igen. For det første at mere politik er bedre: et alt for langt, ulæseligt politiksæt sænker efterlevelsen, fordi medarbejderne ikke kan finde eller rumme det, så korthed og klarhed er sikkerhedsegenskaber. For det andet at selve politikken yder beskyttelse; den er en administrativ kontrol, der former adfærd og muliggør håndhævelse, men den mindsker kun risiko, når den bakkes op af tekniske kontroller, træning og overvågning, der gør de fastsatte regler virkelige. Sikkerhedspolitikken er således bindevævet mellem governance og de operationelle kontroller, der er dokumenteret andetsteds - ikke en erstatning for dem."},"edges":[{"type":"part-of","to":"security/governance","confidence":"high","strength":"normal"},{"type":"mitigates","to":"ai/shadow-ai","confidence":"high","strength":"normal"},{"type":"mandates","to":"security/data-classification","why":{"en":"The policy usually requires that information be sorted by sensitivity so each kind gets the right protection.","da":"Politikken kræver typisk, at information inddeles efter følsomhed, så hver slags får den rette beskyttelse."},"confidence":"medium","strength":"normal"}],"depth":0,"sources":[{"title":"Cyber Security Fast Track - Ordliste","tier":"course-material"},{"title":"ISO/IEC 27002:2022 - Control 5.1, Policies for information security","tier":"standard","publisher":"ISO/IEC"}],"draft":true}