Mappningar mot standarder och ramverk
Referenstabellerna på den här sidan behåller ramverkens egna namn och formuleringar på engelska – beteckningar, beskrivningar och motiveringar – så att de stämmer överens med källdokumenten.
Merula kopplar var och en av sina tjugosex kontroller av domänens säkerhetsläge till de tekniska standarder, säkerhetsramverk och vägledningsteman som kontrollen rimligen kan stödja. Det här är tekniska relevansmappningar: de hjälper team att återanvända data om säkerhetsläget i revisioner, upphandlingsgranskningar och arbete med säkerhetsstyrning. De är inte certifieringar, juridiska bedömningar eller påståenden om fullständig regelefterlevnad.
Mappningarna underhålls tillsammans med kontrollmotorn och återspeglas i etikettraden i tjänsten, så att den offentliga referensen och instrumentpanelen bygger på samma källa.
Standarder beskriver vad varje kontroll testar; ramverk beskriver var resultaten kan vara användbara som stödjande underlag; regulatoriska teman är begränsade till områden som är relevanta för NIS2. Regelefterlevnad omfattar mer än en domänövervakare kan täcka; resten av bilden är kundens eget informationssäkerhetsarbete.
Den redaktionella genomgången av regelverkens omfattning och gränser finns under Stöd för regelefterlevnad.
Så läser du mappningarna
Alla mappningar betyder inte samma sak. Var och en nedan har en relationstyp som anger hur starkt kontrollen hänger ihop med referensen – så att en grundläggande signal aldrig läses som en åtgärd för regelefterlevnad, och en riskkategori aldrig läses som ett påstående om överensstämmelse. Stödjande underlag är det vanliga fallet, så en referens utan etikett är stödjande underlag; bara de tre starkare eller mer specifika typerna – normativt krav, riskrelevans och driftshygien – har en etikett.
- Normativt krav
- Kontrollen verifierar en specifik konfigurationsregel, observerbar utifrån, från en namngiven teknisk standard. Det är den starkaste tekniska relation som Merula gör anspråk på, men bara för den regel som kontrollen faktiskt testar.
- Stödjande underlag
- Kontrollen ger tekniskt underlag, observerbart utifrån, som stöder en bredare åtgärd i ett ramverk eller ett regulatoriskt tema. Det är ett underlag bland många och räcker inte ensamt för att visa överensstämmelse.
- Riskrelevans
- Kontrollen är relevant för en risktaxonomi (OWASP). Den kan bidra till att minska den namngivna riskkategorin, men en riskkatalog är inget regelverk för efterlevnad, och mappningen är aldrig ett påstående om överensstämmelse.
- Driftshygien
- En grundläggande signal om inventering, nåbarhet eller upptäckbarhet. Användbar i driften, men den har ingen mappning mot ramverk eller regelverk – att presentera den som en åtgärd för regelefterlevnad skulle överdriva vad den belägger.
Mappningarna är en-till-många: en kontroll kan stödja mer än en referens inom ett ramverk, och varje referens märks som primär – den referens som kontrollen stöder mest direkt – eller sekundär (visas underordnad, med prefixet ”även:”), en verklig men svagare eller mer indirekt koppling. Där en mappning kan ifrågasättas eller inte är självklar står en motivering på en mening under den.
Europeiskt regulatoriskt sammanhang
NIS2 är det regulatoriska tema på EU-nivå som Merulas iakttagelser oftast mappas mot. Sammanfattningen nedan är inriktad på mappningen; den redaktionella genomgången av vad direktivet kräver – och var Merulas gräns går – finns under Stöd för regelefterlevnad.
NIS2 artikel 21.2
NIS2 artikel 21.2 kräver att väsentliga och viktiga entiteter vidtar lämpliga och proportionella åtgärder för hantering av cybersäkerhetsrisker. Merula gör inte en organisation NIS2-efterlevande, men ger kontinuerligt externt underlag för utvalda tekniska områden som överlappar med artikel 21.2. Varje mappning per kontroll är stödjande underlag, inte överensstämmelse.
Relevanta områden:
- Cyberhygien
- Kryptografi och kryptering
- Transportsäkerhet (e-post och webb under överföring)
- Upptäckt av ändringar och larm
- Extern konfigurationsglidning
Relevanta Merula-kontroller:
- TLS-certifikat och protokollkonfiguration
- SPF, DKIM och DMARC
- STARTTLS, MTA-STS, TLS-RPT och DANE
- DNSSEC och CAA
- HTTP-säkerhetshuvuden
- security.txt (kanal för rapportering av sårbarheter)
- Tillgänglighet, domänens utgångsdatum och registrarlås (kontinuitet)
Avgränsning: Merula täcker inte riskanalys, kontinuitetshantering, säkerhet i leveranskedjan, personalsäkerhet, åtkomstkontroll, intern tillgångshantering, krishantering eller juridiskt efterlevnadsarbete.
Säkerhetsvägledning och applikationsnära standarder
OWASP Secure Headers
Kontrollen av HTTP-säkerhetshuvuden följer den rekommenderade grundnivån från OWASP Secure Headers Project, där de signalerna är observerbara utifrån på de testade ändpunkterna. Den rapporterar en blandning av moderna skydd och äldre huvuden: de moderna (HSTS, Content-Security-Policy, skydd mot inramning, skydd av innehållstyp) bär säkerhetsvikten, medan äldre huvuden och huvuden som avslöjar versioner redovisas som hygienanteckningar i stället för att bedömas som säkerhetsåtgärder.
Relevanta Merula-kontroller:
- HTTP-säkerhetshuvuden
- HSTS
- Skydd mot inramning
- Skydd av innehållstyp
- Säkerhetsflaggor för cookies där Set-Cookie-huvuden är observerbara utifrån
- Huvuden som avslöjar versioner (hygien)
- Utvalda CORS-iakttagelser där de är observerbara utifrån på testade ändpunkter
OWASP Top 10:2025
Hänvisar till den slutliga utgåvan av OWASP Top 10:2025 (presenterad i november 2025). Kategoriernas namn och nummer är kontrollerade mot den utgåvan – observera att 2025 års utgåva numrerade om Security Misconfiguration till A02 (från A05 i 2021 års utgåva), flyttade Cryptographic Failures till A04 (från A02) och kortade A07 till ”Authentication Failures”.
OWASP Top 10 är en katalog för riskmedvetenhet, inte ett regelverk för efterlevnad – så de här mappningarna är riskrelevans, aldrig överensstämmelse. Merula bedömer inte hela Top 10; de flesta kategorier kräver åtkomst till koden, autentiserad åtkomst eller åtkomst till applikationens inre delar. Merula kopplar bara iakttagelser som är observerbara utifrån till den lilla uppsättning kategorier där en domänövervakare verkligen kan belägga en del av felmönstret.
Relevanta kategorier. Mappningen görs per iakttagelse: en kontroll kopplas till en kategori bara när en specifik iakttagelse visar den relevanta svagheten, inte som standard. Listorna anger de kontroller vars iakttagelser kan kopplas till respektive kategori.
- A02:2025 Security Misconfiguration – HTTP-säkerhetshuvuden, syntax för SPF/DKIM/DMARC, förekomst av MTA-STS / STARTTLS / TLS-RPT / DANE.
- A04:2025 Cryptographic Failures – giltighet för TLS-certifikat och certifikatkedja, protokoll- och chifferkonfiguration, DNSSEC-validering, CAA-begränsningar.
- Begränsad signal, observerbar utifrån, inom A01:2025 Broken Access Control – enbart iakttagelser om CORS och cookie-SameSite.
- Begränsad signal inom A07:2025 Authentication Failures, bara där validering av TLS-certifikatets värdnamn eller kedja påverkar serverns identitet. Merula bedömer inte användarautentisering, sessioner, identitetsleverantörer eller kontokontroller.
Avgränsning: Merula är inte en säkerhetsskanner för applikationer, ett penetrationstest eller ett verktyg för kodgranskning. De övriga sex kategorierna i OWASP Top 10 ligger utanför omfattningen eftersom de kräver åtkomst som Merula inte har.
ENISA:s vägledning om e-post
ENISA lyfter fram e-postautentisering (SPF, DKIM, DMARC) och transportsäkerhet för SMTP (STARTTLS, MTA-STS, TLS-RPT, DANE) som en del av åtgärderna för hantering av cybersäkerhetsrisker enligt NIS2, senast i sin NIS2 Technical Implementation Guidance (på engelska) ↗. Den vägledningen är ordnad efter NIS2-åtgärd snarare än efter e-postmekanism, så Merula hänvisar till den som stödjande sammanhang för kontrollerna av e-postautentisering och transportsäkerhet, i stället för att mappa varje kontroll mot ett namngivet ENISA-”område”. Referenserna per mekanism för de kontrollerna finns i tabellerna för CIS Controls v8 och NIST SP 800-177, och NIS2-temana under det europeiska regulatoriska sammanhanget ovan.
ENISA DNS Security
ENISA — Good Practices Guide for Deploying DNSSEC · ENISA (European Union Agency for Cybersecurity) · auktoritativ källa (på engelska) ↗
EU-level guidance on deploying DNSSEC — signing authoritative zones and enabling validation on resolvers. Merula's DNSSEC check maps to this guide's deployment area; CAA is out of its scope (RFC 6844 postdates it) and carries no ENISA mapping.
| Merula-kontroll | Relevant område i ENISA:s DNS-vägledning |
|---|---|
| CK·09 DNSSEC |
|
ENISA – vidare läsning
Ytterligare publikationer från ENISA påverkar hur Merula ser på domänidentitet, hotbild och kontinuerlig övervakning av säkerhetsläget. De citeras som externt sammanhang; ingen av dem är ett påstående från Merula om regelefterlevnad, och ingen innebär att ENISA ställer sig bakom Merula.
ENISA:s Threat Landscape 2025 är hotbild snarare än en uppsättning kontroller, och finns därför inte med i mappningstabellerna ovan. ENISA:s vägledningar om god praxis för e-postsäkerhet och DNS-säkerhet, som redan är mappade per kontroll i de tabellerna, täcker de specifika områdena; Threat Landscape 2025 ligger bakom dem alla och förklarar varför kontinuerlig hygien spelar roll.
- ENISA Threat Landscape 2025 (på engelska) – referens för hotbilden. En hotcentrerad analys av incidenter i EU (oktober 2025). Bakgrund till varför kontinuerlig hygien i den offentliga konfigurationen spelar roll. auktoritativ källa (på engelska) ↗
- ENISA, DNS Identity (2023) – bakgrund för ämnen som rör domänidentitet, registrarer och domänens livscykel och som överlappar med Merulas kontroller av DNS, CAA och domänens utgångsdatum.
- ENISA, Secure by Design and Default Playbook, utkast för remiss, 2026 (på engelska) ↗ – lyfter fram härdning som standard, vägledande skydd och att hjälpa användare att upprätthålla en säker grundnivå över tid. Merula tillämpar en smal del av den idén på domänens offentliga säkerhetsläge; det är inte en produkt som är certifierad enligt Secure by Design.
Ramverk för informationssäkerhet
ISO/IEC 27001:2022
Information security, cybersecurity and privacy protection — Information security management systems · ISO/IEC · auktoritativ källa (på engelska) ↗
Merula ger tekniskt underlag, observerbart utifrån, för utvalda ämnen i ISO/IEC 27001:2022 Annex A. Tabellen nedan kopplar varje kontroll till det Annex A-ämne den ger stödjande underlag för, och anger ämnet med dess kontrollnummer från 2022 inom parentes. Mappningen görs på ämnesnivå: en domänövervakare belägger det tekniska lagret, medan organisationens ledningssystem för informationssäkerhet (ISMS) genomför själva säkerhetsåtgärden.
| Merula-kontroll | Ämne i ISO/IEC 27001:2022 Annex A |
|---|---|
| CK·07 DNS CAA |
|
| CK·09 DNSSEC |
|
| CK·10 TLS-certifikat |
|
| CK·11 SPF |
|
| CK·12 DKIM |
|
| CK·13 DMARC |
|
| CK·14 STARTTLS |
|
| CK·15 MTA-STS |
|
| CK·16 TLS-RPT |
|
| CK·17 DANE (TLSA) |
|
| CK·18 HTTP-säkerhetshuvuden |
|
| CK·19 HTTP-tillgänglighet |
|
| CK·20 Heartbeat |
|
| CK·23 security.txt |
|
| CK·24 Domänregistreringens utgångsdatum |
|
| CK·25 Registrarlås |
|
| CK·26 RPKI-ruttursprung |
|
CIS Controls v8
CIS Critical Security Controls v8 · Center for Internet Security · auktoritativ källa (på engelska) ↗
Prioritised set of cybersecurity best practices grouped into 18 controls and three implementation groups.
| Merula-kontroll | Skyddsåtgärd (safeguard) i CIS Controls v8 som stöds |
|---|---|
| CK·07 DNS CAA |
|
| CK·09 DNSSEC |
|
| CK·10 TLS-certifikat |
|
| CK·11 SPF |
|
| CK·12 DKIM |
|
| CK·13 DMARC |
|
| CK·14 STARTTLS |
|
| CK·15 MTA-STS |
|
| CK·17 DANE (TLSA) |
|
| CK·18 HTTP-säkerhetshuvuden |
|
Internationella referensramverk
NIST:s publikationer används som referens långt utanför amerikanska federala system. De finns med här för köpare som redan anpassar sin interna terminologi efter NIST, inte som ett primärt positioneringsmål för Merula.
NIST CSF 2.0
Cybersecurity Framework 2.0 · NIST · auktoritativ källa (på engelska) ↗
Function-and-category framework for cybersecurity risk management. Govern, Identify, Protect, Detect, Respond, Recover.
| Merula-kontroll | Utfall (outcome) i NIST CSF 2.0 som stöds |
|---|---|
| CK·07 DNS CAA |
|
| CK·09 DNSSEC |
|
| CK·10 TLS-certifikat |
|
| CK·11 SPF |
|
| CK·12 DKIM |
|
| CK·13 DMARC |
|
| CK·14 STARTTLS |
|
| CK·15 MTA-STS |
|
| CK·16 TLS-RPT |
|
| CK·17 DANE (TLSA) |
|
| CK·18 HTTP-säkerhetshuvuden |
|
| CK·19 HTTP-tillgänglighet |
|
| CK·20 Heartbeat |
|
| CK·23 security.txt |
|
| CK·24 Domänregistreringens utgångsdatum |
|
| CK·25 Registrarlås |
|
| CK·26 RPKI-ruttursprung |
|
NIST SP 800-177 Rev. 1
Trustworthy Email · NIST · auktoritativ källa (på engelska) ↗
Amerikansk federal vägledning om att säkra e-postinfrastruktur. Den finns med eftersom dess vägledning om SPF, DKIM, DMARC och transportsäkerhet för SMTP används som referens långt utanför amerikanska federala system. Avsnittshänvisningarna är tänkta som praktiska pekare för driftansvariga och bör stämmas av mot den aktuella publikationen när de används i formella upphandlingssvar.
| Merula-kontroll | Avsnittshänvisning i NIST SP 800-177 |
|---|---|
| CK·11 SPF |
|
| CK·12 DKIM |
|
| CK·13 DMARC |
|
| CK·14 STARTTLS |
|
| CK·15 MTA-STS |
|
| CK·16 TLS-RPT |
|
| CK·17 DANE (TLSA) |
|
Avsnittsnumren är kontrollerade mot innehållsförteckningen i NIST SP 800-177 Rev. 1. MTA-STS (§5.2.5) och TLS-RPT (§5.2.7) omfattas av den reviderade publikationen, som är senare än deras RFC:er.
NIST SP 800-53 Rev. 5
Security and Privacy Controls for Information Systems and Organizations · NIST · auktoritativ källa (på engelska) ↗
Catalogue of security and privacy controls used by US federal systems and broadly cited in private-sector security programmes.
| Merula-kontroll | Säkerhetsåtgärd (control) i NIST SP 800-53 Rev. 5 som stöds |
|---|---|
| CK·09 DNSSEC |
|
| CK·10 TLS-certifikat |
|
| CK·11 SPF |
|
| CK·12 DKIM |
|
| CK·13 DMARC |
|
| CK·14 STARTTLS |
|
| CK·15 MTA-STS |
|
| CK·17 DANE (TLSA) |
|
| CK·18 HTTP-säkerhetshuvuden |
|
| CK·19 HTTP-tillgänglighet |
|
| CK·20 Heartbeat |
|
Ytterligare NIST-referens. Kontrollen av RPKI-ruttursprung (CK·26) hänger också ihop med NIST SP 800-189 (på engelska) ↗, Resilient Interdomain Traffic Exchange – den NIST-publikation som behandlar RPKI, ROA och validering av BGP-ursprung.
Grundläggande signaler och driftsignaler
Vissa kontroller är signaler om inventering, nåbarhet eller upptäckbarhet snarare än säkerhetsåtgärder. De är användbara i driften – Merula övervakar dem ändå och larmar vid ändringar – men de har ingen mappning mot ramverk eller regelverk, eftersom att en post finns inte belägger en säkerhetsåtgärd. Att presentera dem som signaler för regelefterlevnad skulle överdriva vad de visar.
Det är därför de breda DNS-posterna – A, AAAA, MX, NS, CNAME, www och TXT – står här snarare än under ENISA DNS: en DNS-kontroll behandlas som driftshygien om den inte belägger en specifik säkerhetsåtgärd, så som DNSSEC och CAA gör.
- CK·01 DNS A
- CK·02 DNS AAAA
- CK·03 DNS MX
- CK·04 DNS NS
- CK·05 DNS CNAME
- CK·06 DNS www
- CK·08 DNS TXT
- CK·22 sitemap.xml
- CK·21 robots.txt
Tekniska standarder och specifikationer
Varje kontroll vilar på namngivna standarder, specifikationer eller erkänd säkerhetsvägledning där sådana referenser finns. Där en kontroll mappas mot ett bredare ramverk beskriver mappningen stödjande underlag snarare än regelefterlevnad.
Den fullständiga referenslistan över RFC:er, W3C-specifikationer och branschens grundnivåer finns i avsnittet om standarder och RFC:er under Stöd för regelefterlevnad.
Underhåll
Mappningarna granskas kvartalsvis och när ett refererat ramverk, regelverk eller en standard ändras väsentligt. Nya kontroller lanseras inte utan sina mappningsmetadata. Den strukturerade matrisen underhålls tillsammans med kontrollmotorn och återspeglas i den offentliga dokumentationen i Trust Centre.
5 juli 2026. Revidering av mappningarna: varje referens kontrollerad mot sin auktoritativa källa, och varje mappning gjord en-till-många med primär/sekundär nivå och motivering per rad. Utfallen i NIST CSF rättade (TLS-RPT till upptäckt, registrarlås till infrastrukturens motståndskraft) och e-postautentisering förankrad i autentisering (PR.AA-03) snarare än datakonfidentialitet; säkerhetsåtgärden för huvuden i NIST SP 800-53 flyttad till konfigurationsinställningar; namn och nummer på ämnen i ISO/IEC 27001:2022 Annex A rättade; CIS Controls v8 9.5 markerad som den starkaste e-postmappningen; ENISA:s e-postvägledning flyttad till löptext där ingen publikation stöder ett område per kontroll. Avsnittsnummer i NIST SP 800-177 och kategorinamn i OWASP Top 10:2025 kontrollerade på nytt och bekräftade oförändrade.