Merula
compliance support · honest scope

Compliance support

Merula gives teams continuous technical evidence for the domain controls they depend on: DNS, TLS certificates, email authentication, mail transport security, web headers, availability, web hygiene, domain lifecycle and routing. This page explains how those findings relate to recognised standards, security frameworks and guidance — and where the boundary is.

Merula does not certify legal compliance. It continuously monitors externally visible technical controls that commonly support cyber hygiene, audit readiness, customer assurance and NIS2-related risk management. Throughout, a mapping means Merula provides technical evidence that can support a control — never a certification or a claim of full compliance.

OWASP Secure Headers

The HTTP-headers check aligns with the OWASP Secure Headers Project's recommended baseline. Each finding maps to one specific recommendation: missing HSTS, missing X-Content-Type-Options, missing frame-protection (X-Frame-Options or CSP frame-ancestors), version-disclosing headers (Server, X-Powered-By, X-AspNet-Version), and Set-Cookie security flags.

OWASP Top 10:2025

OWASP Top 10 is a risk-awareness catalogue, not a compliance regime — so these are risk-relevance mappings, not conformance claims. We reference the 2025 release. Only a small set of categories has externally observable signals that a domain monitor can genuinely evidence from outside the application; the rest require code-level, authenticated or application-internal access we do not have.

Note: in the 2025 release, Security Misconfiguration moved up from A05 (in 2021) to A02 — the second-most critical category in the consensus. That is the category Merula's headers, email-auth and transport findings most often relate to.

The mapping is at the level of specific findings: a check contributes to a category only when it surfaces the relevant weakness, not by default. The lists below name the checks whose findings can map to each category.

CWEs these external checks can surface, by category:

These CWE references describe the externally observable weaknesses Merula can surface today. They are finding-level references, not a claim of full category or CWE coverage.

EU NIS2 Directive — Article 21(2)

NIS2 requires essential and important entities to apply appropriate and proportionate cybersecurity risk-management measures. Merula does not determine scope or compliance, but several Article 21(2) themes can be supported by external technical evidence from the public domain layer:

What Merula does not cover under NIS2:

Merula provides continuous external evidence for selected technical controls related to the cyber-hygiene and cryptography parts of NIS2 Article 21(2) — specifically (g), (h), the detection side of (b), (c) through domain-registration-expiry monitoring, and the disclosure channel of (e) through security.txt.

Recognised security guidance

Merula's email-authentication and transport checks are built on widely used internet standards, and the case for watching them continuously is made by recognised security authorities. The UK's National Cyber Security Centre, in its email-security and anti-spoofing guidance, recommends that organisations deploy SPF, DKIM and DMARC to reduce domain spoofing, move a DMARC policy towards enforcement in stages — monitoring the reports before tightening — and protect email in transit with TLS. Those are the same controls Merula monitors and the same staged journey it helps you follow.

Reference: NCSC (UK) — Email security and anti-spoofing. UK National Cyber Security Centre, Email security and anti-spoofing guidance.

European threat context

ENISA's Threat Landscape 2025 is a threat-centric analysis of incidents across the EU — the externally documented reason continuous domain hygiene is worth the attention. It reinforces the case for continuous visibility: the pattern of overlapping, persistent campaigns it describes is exactly what makes point-in-time checks insufficient.

A Merula finding is technical evidence about the public layer of your domains — what is observable from outside, and how it has changed over time.

Reference: ENISA Threat Landscape 2025 — threat-context reference. ENISA, Threat Landscape 2025 (October 2025) — a threat-centric analysis of around 4,875 incidents across the EU, July 2024 – June 2025.

Standards & RFCs

Every check is grounded in named standards, specifications or recognised security guidance. We avoid vague "best practice" language where a more precise reference exists. The chip strip on each check in your dashboard surfaces which standards that check evidences.

IETF (RFC)

Web platform (W3C / WHATWG)

Modern browser-platform headers aren't IETF-tracked. The HTTP security-headers check covers the W3C / WHATWG specs: CSP Level 3, Cross-Origin-Opener-Policy, COEP, CORP, Referrer Policy, Permissions Policy, and Fetch (CORS). The recommended baseline we follow is the OWASP Secure Headers Project.

Industry baselines

Continuous evidence over time

Each check runs on a cadence matched to how fast its signal changes: most every hour on every enabled domain, the SMTP transport probes (STARTTLS, DANE) every six hours, the domain-registry and registrar-lock checks daily, and route-origin (RPKI) weekly — within the connection, registry and external-source limits each one faces. Each result is recorded; every status transition writes a change event. The audit trail is per-standard, not just per-check — you can answer "when did our RFC 8461 enforcement break?" with a specific change event, not a forensic exercise.

External references & further reading

The sources below inform how Merula is built and explain why continuous domain and email-security hygiene is worth the attention — recognised, independent references from standards bodies, national security authorities and ecosystem requirements.

NIS2 does not mandate a specific DMARC setup for every organisation, but it raises expectations on cybersecurity risk management, governance and effective controls — Merula supports a concrete, externally observable slice of that. The detailed NIS2 mapping is earlier on this page; the full machine-rendered tables are in the framework mappings.

Where Merula's data lives — residency vs sovereignty

We're built and operated under Swedish law, by a Stockholm-based team, under Adspace Nordic AB. Our infrastructure runs in AWS in the Stockholm region, with backups in the same region.

That gives you EU data residency: customer records, check history, alert metadata, and DMARC reports physically reside in EU AWS regions. We do not replicate to non-EU regions, and we do not transfer data to processors outside the EEA except where contractually necessary (Stripe for billing).

It does not give you full data sovereignty. AWS is a US-headquartered provider. Under US law, including the CLOUD Act, US authorities may seek access to data held by US providers even when the data is stored outside the United States. Separate US intelligence authorities, such as Executive Order 12333, are part of the broader legal context considered in EU transfer-risk assessments. The Schrems II ruling (CJEU C-311/18, 2020) and the EU–US Data Privacy Framework sit in that legal landscape. The Framework changes the transfer-risk assessment but does not remove the need for customers with strict sovereignty requirements to make their own assessment.

What this means in practice:

We state this plainly so prospective customers can make the assessment with the actual facts in hand.

The structured matrix

For the structured check-by-check matrix, see Standards & framework mappings.