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.
- 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.
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
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 Security
ENISA — Good Practices for Email Security · ENISA (European Union Agency for Cybersecurity) · authoritative source ↗
EU-level guidance on securing email transport and authenticating senders.
| Merula check | Relevant ENISA email-security guidance area |
|---|---|
| CK·11 SPF | |
| CK·12 DKIM | |
| CK·13 DMARC | |
| CK·14 STARTTLS | |
| CK·15 MTA-STS | |
| CK·16 TLS-RPT | |
| CK·17 DANE (TLSA) |
ENISA DNS Security
ENISA — Good Practices for the Internet Infrastructure (DNS) · ENISA (European Union Agency for Cybersecurity) · authoritative source ↗
EU-level guidance on DNS hardening, including DNSSEC and resolver hygiene.
| Merula check | Relevant ENISA DNS guidance area |
|---|---|
| CK·07 DNS CAA | DNS |
| CK·09 DNSSEC | DNS |
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, Security 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 — at topic level rather than exact control number, because a domain monitor evidences the technical layer and the organisation's ISMS implements the controls.
| Merula check | ISO/IEC 27001:2022 Annex A topic |
|---|---|
| CK·07 DNS CAA | Use of cryptography |
| CK·09 DNSSEC | Use of cryptography |
| CK·10 TLS certificate | Use of cryptography |
| CK·11 SPF | Information transfer |
| CK·12 DKIM | Information transfer |
| CK·13 DMARC | Information transfer |
| CK·14 STARTTLS | Information transfer |
| CK·15 MTA-STS | Information transfer |
| CK·16 TLS-RPT | Information transfer |
| CK·17 DANE (TLSA) | Use of cryptography |
| CK·18 HTTP security headers | Secure configuration |
| CK·19 HTTP availability | ICT readiness for service availability |
| CK·20 Heartbeat | ICT readiness for service availability |
| CK·23 security.txt | Information security incident management |
| CK·24 Domain registration expiry | Asset and configuration information |
| CK·25 Registrar lock | Asset and configuration information |
| CK·26 RPKI route origin | Network security |
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 | 4.1 |
| CK·09 DNSSEC | 4.1, 12.1 |
| CK·10 TLS certificate | 3.10, 4.1 |
| CK·11 SPF | 9.5 |
| CK·12 DKIM | 9.5 |
| CK·13 DMARC | 9.5 |
| CK·14 STARTTLS | 3.10 |
| CK·15 MTA-STS | 3.10 |
| CK·17 DANE (TLSA) | 3.10 |
| CK·18 HTTP security headers | 16.10 |
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 | PR.DS-02 |
| CK·09 DNSSEC | PR.DS-02 |
| CK·10 TLS certificate | PR.DS-02 |
| CK·11 SPF | PR.DS-02 |
| CK·12 DKIM | PR.DS-02 |
| CK·13 DMARC | PR.DS-02 |
| CK·14 STARTTLS | PR.DS-02 |
| CK·15 MTA-STS | PR.DS-02 |
| CK·16 TLS-RPT | PR.PS-01 |
| CK·17 DANE (TLSA) | PR.DS-02 |
| CK·18 HTTP security headers | PR.PS-01 |
| CK·19 HTTP availability | DE.CM-01 |
| CK·20 Heartbeat | DE.CM-01 |
| CK·23 security.txt | ID.RA-08 |
| CK·24 Domain registration expiry | ID.AM-04 |
| CK·25 Registrar lock | ID.AM-04 |
| CK·26 RPKI route origin | PR.IR-01 |
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 | §4.4 |
| CK·12 DKIM | §4.5 |
| CK·13 DMARC | §4.6 |
| CK·14 STARTTLS | §5.2.3 |
| CK·15 MTA-STS | §5.2.5 |
| CK·16 TLS-RPT | §5.2.7 |
| CK·17 DANE (TLSA) | §5.2.4 |
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 | SC-20 |
| CK·10 TLS certificate | SC-12, SC-13 |
| CK·14 STARTTLS | SC-8 |
| CK·15 MTA-STS | SC-8 |
| CK·17 DANE (TLSA) | SC-8, SC-20 |
| CK·18 HTTP security headers | SC-7 |
| CK·19 HTTP availability | SI-4 |
| CK·20 Heartbeat | SI-4 |
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: other DNS checks are treated as operational hygiene unless they evidence 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.