Standards & framework mappings
Merula links each of its twenty-six domain posture checks to the technical standards, security frameworks and guidance themes it can reasonably support. These are technical relevance mappings: they help teams reuse posture data in audits, procurement reviews and security governance work. They are not certifications, legal opinions or claims of full compliance.
The mappings are maintained alongside the check engine and reflected in the in-product chip strip, so the public reference and dashboard use the same source of truth.
Standards describe what each check tests; frameworks describe where the results may be useful as supporting evidence; regulatory themes are limited to NIS2-relevant areas. Compliance is broader than a domain monitor can cover; the rest of the picture is the customer's information-security programme.
For the editorial discussion of regulatory scope and boundaries, see Compliance support.
How to read these mappings
Not every mapping means the same thing. Each one below carries a relationship type that says how strongly the check relates to the reference — so a baseline signal is never read as a compliance control, and a risk category is never read as a conformance claim. Supporting evidence is the common case, so a reference left unlabelled is supporting evidence; only the three stronger or more specific types — normative requirement, risk relevance, operational hygiene — carry a chip.
- Normative requirement
- The check verifies a specific externally observable configuration rule from a named technical standard. This is the strongest technical relationship Merula claims, but only for the rule the check actually tests.
- Supporting evidence
- The check provides externally observable technical evidence that supports a broader framework control or regulatory theme. It is one input among many, not sufficient on its own to demonstrate conformance.
- Risk relevance
- The check is relevant to a risk taxonomy (OWASP). It can help reduce the risk category named, but a risk catalogue is not a compliance regime and the mapping is never a conformance claim.
- Operational hygiene
- A baseline, inventory, reachability or discoverability signal. Useful operationally, but it carries no framework or regulatory mapping — presenting it as a compliance control would overstate what it evidences.
Mappings are one-to-many: a check can support more than one reference within a framework, and each is tagged as primary — the reference the check most directly supports — or secondary (shown subordinate, prefixed "also:"), a real but weaker or more indirect association. Where a mapping is contested or non-obvious, a one-sentence rationale sits beneath it.
European regulatory context
NIS2 is the EU-level regulatory theme Merula's findings most often map to. The summary below is mapping-oriented; the editorial discussion of what it requires — and where Merula's boundary lies — is on Compliance support.
NIS2 Article 21(2)
NIS2 Article 21(2) requires essential and important entities to apply appropriate and proportionate cybersecurity risk-management measures. Merula does not make an organisation NIS2 compliant, but it provides continuous external evidence for selected technical areas that overlap with Article 21(2). Each per-check mapping is supporting evidence, not conformance.
Relevant areas:
- Cyber hygiene
- Cryptography and encryption
- Transport security (email and web in transit)
- Change detection and alerting
- External configuration drift
Relevant Merula checks:
- TLS certificate and protocol posture
- SPF, DKIM and DMARC
- STARTTLS, MTA-STS, TLS-RPT and DANE
- DNSSEC and CAA
- HTTP security headers
- security.txt (vulnerability-disclosure channel)
- Availability, domain expiry and registrar lock (continuity)
Boundary: Merula does not cover risk analysis, business continuity, supply-chain security, HR security, access control, internal asset management, crisis management or legal compliance work.
Security guidance and application-facing standards
OWASP Secure Headers
The HTTP security headers check follows the OWASP Secure Headers Project's recommended baseline where those signals are externally observable on tested endpoints. It reports a mix of modern controls and legacy headers: the modern ones (HSTS, Content-Security-Policy, frame protection, content-type protection) carry the security weight, while legacy or version-disclosing headers are surfaced as hygiene notes rather than graded as controls.
Relevant Merula checks:
- HTTP security headers
- HSTS
- Frame protection
- Content-type protection
- Cookie security flags where Set-Cookie headers are externally observable
- Version-disclosing headers (hygiene)
- Selected CORS findings where externally observable on tested endpoints
OWASP Top 10:2025
References the OWASP Top 10:2025 final release (presented November 2025). Category titles and numbers are verified against that release — note that 2025 renumbered Security Misconfiguration to A02 (from A05 in 2021), moved Cryptographic Failures to A04 (from A02), and shortened A07 to "Authentication Failures".
OWASP Top 10 is a risk-awareness catalogue, not a compliance regime — so these mappings are risk relevance, never conformance. Merula does not assess the full Top 10; most categories require code-level, authenticated or application-internal access. Merula only relates externally observable findings to the small set of categories where a domain monitor can genuinely evidence part of the failure mode.
Relevant categories. The mapping is finding-level: a check relates to a category only when a specific finding surfaces the relevant weakness, not by default. The lists name the checks whose findings can map to each category.
- A02:2025 Security Misconfiguration — HTTP security headers, SPF/DKIM/DMARC syntax, MTA-STS / STARTTLS / TLS-RPT / DANE presence.
- A04:2025 Cryptographic Failures — TLS certificate and chain validity, protocol and cipher posture, DNSSEC validation, CAA constraints.
- Limited externally observable signal in A01:2025 Broken Access Control — CORS and cookie-SameSite findings only.
- Limited A07:2025 Authentication Failures signal only where TLS certificate hostname or chain validation affects server identity. Merula does not assess user authentication, sessions, identity providers or account controls.
Boundary: Merula is not an application security scanner, penetration test or code review tool. The other six OWASP Top 10 categories are out of scope because they require access Merula does not have.
ENISA email guidance
ENISA promotes email authentication (SPF, DKIM, DMARC) and SMTP transport security (STARTTLS, MTA-STS, TLS-RPT, DANE) as part of the cybersecurity risk-management measures under NIS2, most recently in its NIS2 Technical Implementation Guidance ↗. That guidance is organised by NIS2 measure rather than by email mechanism, so Merula cites it as supporting context for the email-authentication and transport-security checks rather than mapping each check to a named ENISA "area". The per-mechanism references for those checks are in the CIS Controls v8 and NIST SP 800-177 tables, and the NIS2 themes are in the European regulatory context above.
ENISA DNS Security
ENISA — Good Practices Guide for Deploying DNSSEC · ENISA (European Union Agency for Cybersecurity) · authoritative source ↗
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 check | Relevant ENISA DNS guidance area |
|---|---|
| CK·09 DNSSEC |
|
ENISA — further reading
Further ENISA publications inform how Merula thinks about domain identity, threat context and continuous secure-posture monitoring. They are cited as external context; none is a Merula compliance claim or an ENISA endorsement of Merula.
ENISA's Threat Landscape 2025 is threat context rather than a control set, so it is not in the mapping tables above. ENISA's email-security and DNS-security good-practice guidance, already mapped per check in those tables, covers the specific areas; Threat Landscape 2025 sits behind all of them, explaining why continuous hygiene matters.
- ENISA Threat Landscape 2025 — threat-context reference. A threat-centric analysis of incidents across the EU (October 2025). Context for why continuous public-posture hygiene matters. authoritative source ↗
- ENISA, DNS Identity (2023) — background for domain identity, registrar and lifecycle topics that overlap with Merula's DNS, CAA and domain-expiry checks.
- ENISA, Secure by Design and Default Playbook, draft for consultation, 2026 ↗ — highlights default hardening, guided protection and helping users maintain a secure baseline over time. Merula applies a narrow slice of this idea to public domain posture; it is not a Secure-by-Design-certified product.
Information security frameworks
ISO/IEC 27001:2022
Information security, cybersecurity and privacy protection — Information security management systems · ISO/IEC · authoritative source ↗
Merula provides externally observable technical evidence for selected ISO/IEC 27001:2022 Annex A topics. The table below maps each check to the Annex A topic it supports evidence for, naming the topic with its 2022 control number in parentheses. The mapping is topic-level: a domain monitor evidences the technical layer, while the organisation's ISMS implements the control.
| Merula check | ISO/IEC 27001:2022 Annex A topic |
|---|---|
| CK·07 DNS CAA |
|
| CK·09 DNSSEC |
|
| CK·10 TLS certificate |
|
| 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 security headers |
|
| CK·19 HTTP availability |
|
| CK·20 Heartbeat |
|
| CK·23 security.txt |
|
| CK·24 Domain registration expiry |
|
| CK·25 Registrar lock |
|
| CK·26 RPKI route origin |
|
CIS Controls v8
CIS Critical Security Controls v8 · Center for Internet Security · authoritative source ↗
Prioritised set of cybersecurity best practices grouped into 18 controls and three implementation groups.
| Merula check | CIS Controls v8 safeguard supported |
|---|---|
| CK·07 DNS CAA |
|
| CK·09 DNSSEC |
|
| CK·10 TLS certificate |
|
| CK·11 SPF |
|
| CK·12 DKIM |
|
| CK·13 DMARC |
|
| CK·14 STARTTLS |
|
| CK·15 MTA-STS |
|
| CK·17 DANE (TLSA) |
|
| CK·18 HTTP security headers |
|
International reference frameworks
NIST publications are widely referenced beyond US federal systems. They are included here for buyers who already align their internal vocabulary to NIST, not as a primary positioning target for Merula.
NIST CSF 2.0
Cybersecurity Framework 2.0 · NIST · authoritative source ↗
Function-and-category framework for cybersecurity risk management. Govern, Identify, Protect, Detect, Respond, Recover.
| Merula check | NIST CSF 2.0 outcome supported |
|---|---|
| CK·07 DNS CAA |
|
| CK·09 DNSSEC |
|
| CK·10 TLS certificate |
|
| 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 security headers |
|
| CK·19 HTTP availability |
|
| CK·20 Heartbeat |
|
| CK·23 security.txt |
|
| CK·24 Domain registration expiry |
|
| CK·25 Registrar lock |
|
| CK·26 RPKI route origin |
|
NIST SP 800-177 Rev. 1
Trustworthy Email · NIST · authoritative source ↗
US federal guidance on securing email infrastructure. Included because its SPF, DKIM, DMARC and SMTP transport-security guidance is widely referenced beyond US federal systems. Section references are provided as operator-facing pointers and should be checked against the current publication when used in formal procurement responses.
| Merula check | NIST SP 800-177 section reference |
|---|---|
| CK·11 SPF |
|
| CK·12 DKIM |
|
| CK·13 DMARC |
|
| CK·14 STARTTLS |
|
| CK·15 MTA-STS |
|
| CK·16 TLS-RPT |
|
| CK·17 DANE (TLSA) |
|
Section numbers were verified against the NIST SP 800-177 Rev. 1 table of contents. MTA-STS (§5.2.5) and TLS-RPT (§5.2.7) are covered by the revised publication, which postdates their RFCs.
NIST SP 800-53 Rev. 5
Security and Privacy Controls for Information Systems and Organizations · NIST · authoritative source ↗
Catalogue of security and privacy controls used by US federal systems and broadly cited in private-sector security programmes.
| Merula check | NIST SP 800-53 Rev. 5 control supported |
|---|---|
| CK·09 DNSSEC |
|
| CK·10 TLS certificate |
|
| CK·11 SPF |
|
| CK·12 DKIM |
|
| CK·13 DMARC |
|
| CK·14 STARTTLS |
|
| CK·15 MTA-STS |
|
| CK·17 DANE (TLSA) |
|
| CK·18 HTTP security headers |
|
| CK·19 HTTP availability |
|
| CK·20 Heartbeat |
|
Additional NIST reference. The RPKI route-origin check (CK·26) also relates to NIST SP 800-189 ↗, Resilient Interdomain Traffic Exchange — the NIST publication that covers RPKI, ROA and BGP origin validation.
Baseline & operational signals
Some checks are inventory, reachability or discoverability signals rather than security controls. They are useful operationally — Merula still monitors them and alerts on change — but they carry no framework or regulatory mapping, because a record's presence does not evidence a control. Presenting them as compliance signals would overstate what they show.
This is why the broad DNS records — A, AAAA, MX, NS, CNAME, www and TXT — sit here rather than under ENISA DNS: a DNS check is treated as operational hygiene unless it evidences a specific security control, as DNSSEC and CAA do.
- 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
Technical standards & specifications
Each check is grounded in named standards, specifications or recognised security guidance where such references exist. Where a check maps to a broader framework, the mapping describes supporting evidence rather than compliance.
The full RFC, W3C and industry-baseline reference list lives in the Standards & RFCs section of Compliance support.
Maintenance
Mappings are reviewed quarterly and when a referenced framework, regulation or standard materially changes. New checks are not shipped without their mapping metadata. The structured matrix is maintained alongside the check engine and reflected in the public Trust Centre documentation.
5 July 2026. Mapping revision: verified every reference against its authoritative source and made each mapping one-to-many with primary/secondary tiers and per-row rationale. NIST CSF outcomes corrected (TLS-RPT to detection, registrar lock to infrastructure resilience) and email authentication anchored on authentication (PR.AA-03) rather than data confidentiality; NIST SP 800-53 headers control moved to configuration settings; ISO/IEC 27001:2022 Annex A topic names and numbers corrected; CIS Controls v8 9.5 flagged as the strongest email mapping; ENISA email guidance moved to prose where no publication supports a per-check area. NIST SP 800-177 section numbers and OWASP Top 10:2025 titles re-verified and confirmed unchanged.