Compliance posture

DaloyJS is a backend framework, not a managed service, so it cannot certify your deployment for SOC 2, ISO 27001, HIPAA, GDPR, PCI-DSS, NIS2, DORA, or the UK Cyber Security and Resilience Bill on its own. What it cando is provide the technical controls each of those frameworks expects from the application layer so that the controls live in source code where they are reviewed, tested, and version-pinned — rather than in a checklist that drifts away from production.

This page maps DaloyJS's built-in primitives to the control families auditors actually ask about. The mapping is informational, not a legal opinion: organizational controls (employee training, vendor management, physical security, access reviews) remain the operator's responsibility.

Shared technical controls

Most frameworks ask for the same handful of application-layer controls under different names. DaloyJS ships them by default.

SOC 2 (Trust Services Criteria, 2017 with 2022 points of focus)

SOC 2 maps to the Trust Services Criteria. DaloyJS contributes mostly to the Security (Common Criteria) category and partially to Availability and Confidentiality. Privacy and Processing Integrity also get coverage when you turn the schemas into binding contracts.

• CC6.1 / CC6.6 — logical access & boundary protection. Use secureHeaders(), cors(), session(), bearerAuth(), and ipRestriction() on admin routes.
• CC6.7 — data in transit. HSTS via secureHeaders(); TLS termination is the platform's responsibility.
• CC6.8 — protection against malicious software. Supply-chain hardening (no runtime deps, provenance, SBOM,ignore-scripts, SHA-pinned actions, lockfile-source verification).
• CC7.1 / CC7.2 — monitoring & anomaly detection. Structured JSON logs with request-id correlation; Server-Timing for latency monitoring; OpenTelemetry integration documented under Tracing.
• CC7.4 — incident response. Published SECURITY.md, GHSA evidence pattern, and CVSS-keyed patch SLA.
• A1.2 — availability. Rate limiting, load shedding, request timeouts, body-size caps, graceful shutdown hooks.

ISO/IEC 27001:2022 (Annex A)

Picking the 2022 revision (rather than 2013/2017) is the safer call for new certifications — it adds explicit controls for secure coding, threat intelligence, web filtering, and configuration management that DaloyJS already covers out of the box. The mapping below is the short version your auditor can use as evidence for the application-layer controls.

• A.5.7 Threat intelligence— OpenSSF Scorecard, OSV-Scanner, CodeQL, Dependabot, and the published GHSA advisory flow feed the framework's own intel loop; downstream apps inherit the same signals through create-daloy --with-ci.
• A.5.23 Information security for use of cloud services — runtime-parity audits keep behavior identical across Node, Bun, Deno, Cloudflare Workers, and Vercel Edge so the cloud provider is a deployment choice, not a security trade-off.
• A.5.30 ICT readiness for business continuity— graceful shutdown, health endpoints, and lifecycle hooks (see Lifecycle & health).
• A.8.7 Protection against malware— supply-chain controls listed above.
• A.8.8 Management of technical vulnerabilities— the SLA table in SECURITY.md, GHSA flow, OpenSSF Scorecard, CodeQL, Dependabot.
• A.8.9 Configuration management— secure defaults are enforced at boot (secureDefaults enforcement), not just documented.
• A.8.15 Logging— structured logger, request-id correlation, PII redaction.
• A.8.16 Monitoring activities— Server-Timing headers, OpenTelemetry spans, and the structured-log pipeline give downstream SIEM/observability tools the signals they need; rate-limit rejections, schema-validation failures, and JWT rejections all surface as discrete log events with a stable request-id.
• A.8.23 Web filtering — fetchGuard() enforces an egress allow-list pattern from inside the app.
• A.8.24 Use of cryptography— algorithm allow-listing on JWT/JWK; HMAC with algorithm-prefix parsing; timing-safe comparisons.
• A.8.25 Secure development lifecycle — create-daloy --with-ci ships CodeQL, Scorecard, zizmor, Dependabot, CODEOWNERS, and a SECURITY.md template.
• A.8.26 Application security requirements— input validation through Zod/Valibot; OpenAPI contract enforcement before any handler runs.
• A.8.28 Secure coding— documented patterns for SQL injection, command injection, SSRF, CSRF, prototype pollution.
• A.8.32 Change management— SHA-pinned GitHub Actions (verified by verify:actions-pinned), a 24h minimum-release-age cooldown on dependencies, provenance-signed npm publishes, and the verify-* CI gates listed in AGENTS.md make every framework change an auditable, reviewable event.

HIPAA Security Rule (45 CFR § 164.312)

HIPAA cares about Protected Health Information (PHI) handled by Covered Entities and Business Associates. DaloyJS contributes to the Technical Safeguards:

• § 164.312(a) Access Control— unique user identification via session/JWT subject claim; automatic logoff via session TTL; encryption at the cookie layer with signed and rotated keys.
• § 164.312(b) Audit Controls— structured logs with request-id, route, status, latency, and user-id (when authenticated) so a downstream log pipeline can satisfy retention and tamper-evidence requirements (those still need to be configured at the log sink).
• § 164.312(c) Integrity— HMAC for webhook payloads; signed sessions; ETag/Last-Modified for optimistic concurrency on PHI mutations.
• § 164.312(d) Person or Entity Authentication— first-party authentication helpers; tested integrations with AWS Cognito, Microsoft Entra ID, Auth0, Okta, and Clerk.
• § 164.312(e) Transmission Security— HSTS and secure cookies by default; the actual TLS terminator (load balancer, CDN, platform) is out of the framework's scope.
• Practical PHI hygiene. Add field-level redaction in the logger for any field that carries PHI; do not log request bodies on PHI routes; keep the session() cookie httpOnly and sameSite (default behavior).

GDPR (Regulation 2016/679)

GDPR is risk-based; Article 32 (“security of processing”) and Article 25 (“data protection by design and by default”) are where the framework helps most.

• Article 5(1)(f) integrity & confidentiality — secure headers, signed sessions, schema-validated inputs, structured logs with redaction.
• Article 25 data protection by design and by default — secure-by-default body limits, request timeouts, content-type allow-listing, and CSRF/cors defaults; the auditor sees that the insecure paths are opt-in, not the other way around.
• Article 30 records of processing— OpenAPI is generated from the routes themselves, which gives a machine-readable inventory of every endpoint that touches personal data. Pair it with a tagging convention (e.g. x-daloy-data-classes: ["email", "ip"]) so the same spec answers ROPA questions.
• Article 32 security of processing— the “Shared technical controls” table above is the short answer for the application layer; pseudonymization, encryption at rest, and key management still live at the data store.
• Article 33 breach notification (within 72 hours) — the request-id and structured-log primitives make it possible to reconstruct affected sessions; the published CVSS-keyed patch SLA lets controllers describe the “measures taken” section of their breach notification with real numbers rather than aspirations.
• Logging PII responsibly. The logger's redactRecord() already masks well-known secret keys (passwords, tokens, API keys). Extend the redaction list for application-specific PII fields and never log raw request bodies on routes that process personal data.

PCI-DSS v4.0 (software-side controls)

DaloyJS's payments documentation already calls out the SAQ scope consequences of touching a Primary Account Number (PAN) directly. The framework helps with the software-side requirements of v4.0:

• Req 2 secure configurations— secure-by-default headers, content-type allow-listing, and the boot guards that fail-closed on insecure config.
• Req 4 strong cryptography in transit — HSTS via secureHeaders().
• Req 6.2 secure software development— schema-validated inputs, prototype-pollution-safe JSON parsing, header sanitization, path-traversal-safe router, prepared-statement guidance for every ORM in SQL injection.
• Req 6.3 manage vulnerabilities— SECURITY.md SLA, GHSA evidence, dependency-graph monitoring.
• Req 6.4 protect public-facing web applications — CSRF, secure headers, rate limiting, request-id correlation.
• Req 8 strong authentication— first-party session/JWT helpers with algorithm allow-listing.
• Req 10 log and monitor— structured logs with per-request correlation IDs; the retention and tamper-evidence obligations live at the log sink.
• SAQ scope. The strongest control here is not seeing the PAN at all. The payments docs (Stripe, Authorize.Net, Square) document the redirect/hosted-fields patterns that keep you in SAQ-A or SAQ-A-EP rather than SAQ-D.

NIS2 (Directive (EU) 2022/2555) and the EU CRA

NIS2 Article 21 lists the cybersecurity risk-management measures essential and important entities must adopt. The Cyber Resilience Act adds analogous obligations on the vendor side. Both increasingly show up as upstream patch-SLA clauses in procurement.

Are you in scope? (NIS2 self-assessment)

DaloyJS itself is open-source framework software and is not a regulated entity. NIS2 obligations attach to the operator running the service, not to the framework author — so the first question for any team building on Daloy is whether the directive applies to them. Aikido's “NIS2: Who is affected?” write-up summarizes the sector and size tests; the checklist below is the operator-friendly version, oriented around the workloads people actually build with this framework.

You are likely in scope if all three of the following are true:

1. You operate in the EU. NIS2 applies to entities providing services in the Union, even when the entity itself is established outside the EU (Article 26 establishment rules apply for cloud, data centers, CDN, managed services, MSSPs, online marketplaces, online search, social networks, and DNS providers).
2. Your sector is named in Annex I or Annex II. Annex I (essential, “high criticality”) covers energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure (IXPs, DNS, TLDs, cloud computing, data center services, CDN, trust services, electronic communications), ICT service management (B2B, including MSPs and MSSPs), and public administration. Annex II (important, “other critical”)covers postal & courier, waste management, manufacture and distribution of chemicals, food production/processing/distribution, manufacturing (medical devices, computers/electronics, electrical equipment, machinery, motor vehicles, other transport equipment), digital providers (online marketplaces, online search engines, social networks), and research organisations.
3. You meet the size threshold— medium-sized or larger per the EU 2003/361 SME definition: ≥ 50 staff or > €10 million annual turnover or balance sheet. Smaller entities can also be pulled in regardless of size when they are a sole provider in a member state, when a disruption would have a significant impact on public safety / security / health, when they are a qualified trust service provider, TLD name registry, DNS service provider, or public electronic communications provider, or when the member state has designated them as critical under Article 2(2). Public administration entities are in scope under separate Article 2(2)(f) rules.

The two tiers carry different penalty caps and supervisory regimes: essential entities face up to €10 M or 2% of global annual turnover (whichever is higher) and ex-ante supervision; important entities face up to €7 M or 1.4% of global annual turnover and ex-post supervision. Article 20 also makes management bodies personally accountablefor approving the risk-management measures and undergoing cybersecurity training — that is the clause that has been generating the most attention, because the responsibility cannot be delegated to the security team. Member-state transposition deadline was 17 October 2024; most member states have since published national laws with their own registration and reporting portals (the national CSIRT and the single-entry point under Article 23(4)).

If you concluded you are in scope, the Article 21 measure list below plus the EU CRA evidence pack further down are what you point your own auditor at for the framework layer. Most workloads built on Daloy land in Annex I “digital infrastructure” (cloud / data center / CDN), Annex I “ICT service management” (MSP / MSSP), or Annex II “digital providers” (online marketplace / search / social network) — the technical controls in this page were built specifically so a team in those sectors does not have to reconstruct the framework-layer evidence from scratch.

Article 21 risk-management measures (framework-layer mapping)

• Article 20 governance — management body approves the risk-management measures and undergoes cybersecurity training — an organizational obligation on the consumer (cannot be delegated to the security team). The framework layer makes the underlying evidence reviewable: every guardrail listed below lives in source and is enforced by pnpm verify:*, so the management body can be shown version-pinned, auditable proof rather than a slide deck.
• Article 21(2)(a) policies on risk analysis and security of information systems — the secure-by-default baseline plus the boot-guard enforcement.
• Article 21(2)(b) incident handling— SECURITY.md publishes the response targets, escalation contacts, and GHSA evidence format.
• Article 21(2)(d) supply-chain security— npm provenance, SBOM, SHA-pinned third-party Actions, lockfile-source verification, ignore-scripts by default in scaffolded projects.
• Article 21(2)(e) security in network and information systems acquisition, development, and maintenance — the CI bundle from create-daloy --with-ci turns CodeQL, Scorecard, zizmor, Dependabot, and CODEOWNERS on out of the box.
• Article 21(2)(g) basic cyber hygiene practices — documented patterns for sessions, CSRF, SSRF, SQL/command injection, and admin-panel hardening; opinionated runtime protections.
• Article 21(2)(h) use of cryptography— algorithm allow-listing, timing-safe comparisons, HMAC algorithm prefix parsing.
• Article 23 incident reporting (24 h early warning, 72 h notification, 1-month final report to the national CSIRT or competent authority) — this is the consumer's obligation, but the framework ships the technical substrate: per-request structured logs with correlated request IDs, OpenTelemetry-shaped spans, and plugin lifecycle hooks (rate-limit, auth-failure, SSRF-block, body-limit, timeout, onShutdown) suitable for feeding the regulator-facing notification pipeline within the statutory window.
• EU CRA upstream patch SLA— the CVSS-keyed table in SECURITY.md is written specifically so downstream procurement can quote it verbatim.

EU Cyber Resilience Act (Regulation (EU) 2024/2847)

The Cyber Resilience Act places binding obligations on the manufacturer of any “product with digital elements” sold into the EU. DaloyJS itself is free open-source software (the CRA exempts non-commercial OSS development from manufacturer liability under Recital 16 / Article 3(18)), but a downstream commercial product that integrates @daloyjs/core inherits the obligation to demonstrate Annex I conformity for the integrated framework. The full requirement-by-requirement evidence pack lives in SECURITY.md → “EU Cyber Resilience Act mapping”; the table below is the operator-friendly summary.

The two deadlines that matter for downstream consumers: 2026-09-11 (24-hour reporting of actively exploited vulnerabilities to ENISA and the national CSIRT, CRA Article 14) and 2027-12-11 (full Annex I conformity before a product may bear the CE mark, CRA Article 13). DaloyJS commits upstream to both.

This mapping is informational and is not a legal opinion. A downstream conformity assessment for a CE-marked product remains the integrator's responsibility; the evidence above exists so the framework layer of that dossier does not have to be reconstructed from scratch.

UK Cyber Security and Resilience Bill (CSR Bill)

The UK government's Cyber Security and Resilience Bill updates the UK's NIS Regulations 2018, brings managed service providers (MSPs) and certain digital service providers into scope, introduces supply-chain duties for operators of essential services (OES) and relevant digital service providers (RDSPs), and tightens incident reporting to a two-stage 24 h early warning plus 72 h follow-up aligned with EU NIS2. Technical and methodological requirements are expected to track the NCSC Cyber Assessment Framework (CAF) Basic and Enhanced profiles.

DaloyJS itself is open-source framework software — it is not an MSP, OES, RDSP, or designated critical supplier — but apps built on it routinely fall into scope. The table below maps each measure from the April 2025 policy statement to the DaloyJS primitives a regulated team can point at on day one. Because the CSR Bill is closely modeled on NIS2 Article 21, the EU CRA evidence above also carries over almost line-for-line.

Status: the CSR Bill was outlined in the King's Speech 2024 and the policy statement was presented to Parliament in April 2025; duties will be set in secondary legislation and statutory instruments after Royal Assent. This mapping reflects the policy statement as published and will be updated when the Bill is enacted and the technical requirements (expected to track NCSC CAF) are codified.

DORA (Regulation (EU) 2022/2554)

The Digital Operational Resilience Act has applied to EU financial entities and their ICT third-party service providers since 17 January 2025. It is built on five pillars: ICT risk management (Chapter II), ICT-related incident management, classification, and reporting (Chapter III), digital operational resilience testing (Chapter IV), management of ICT third-party risk (Chapter V), and information-sharing arrangements (Chapter VI). The technical detail lives in the Commission's Regulatory Technical Standards, most notably Delegated Regulation (EU) 2024/1774 on ICT risk-management tools and Delegated Regulation (EU) 2024/1773 on subcontracting arrangements.

DaloyJS itself is open-source framework software, not a regulated financial entity and not (on its own) a designated “critical ICT third-party service provider” under Article 31. But apps built on DaloyJS routinely arethe ICT systems that DORA applies to, and the framework layer is something a financial-entity team or its ICT-TPP supplier must be able to point at during a Joint Examination Team review. Because DORA's technical control families overlap heavily with NIS2 Article 21 and the EU CRA Annex I, most of the evidence above carries over directly — the table below summarizes the DORA-specific framing.

This mapping is informational and is not a legal opinion. DORA conformity for a regulated financial entity or for a designated critical ICT third-party service provider remains the operator's responsibility; the evidence above exists so the framework layer of that dossier does not have to be reconstructed from scratch. Critical ICT third-party service provider designation (Article 31) and the resulting Lead Overseer oversight regime are out of scope for an open-source framework.

Operator responsibilities the framework cannot cover

Be upfront about this when you talk to your auditor — conflating application controls with platform or organizational controls is the fastest way to lose credibility:

• TLS termination, key management, KMS/HSM choice live at your load balancer, CDN, or platform.
• Encryption at rest, backup, disaster recovery live at the data store and infrastructure layer.
• Identity provider, MFA enrollment, account recovery live at the IdP (Cognito, Entra ID, Auth0, Okta, Clerk). The framework consumes the resulting tokens; it does not run the IdP.
• Log retention, immutability, SIEM forwarding live at the log sink. The framework emits the structured logs; how long they live and who can delete them is a pipeline concern.
• Vendor management, employee training, access reviews, background checks, physical security are organizational controls. No framework can produce evidence for those.
• Data-processing agreements, standard contractual clauses, transfer impact assessments are legal artifacts.

Suggested artifact pack for an audit

1. The generated openapi.json as the canonical inventory of every public endpoint.
2. The sbom.json emitted by scripts/generate-sbom.ts for the framework version you ship.
3. Your own application's lockfile plus a recent pnpm audit --prod output.
4. The release's npm provenance attestation (visible on the package page) and the matching GitHub Security Advisory entries.
5. A short README mapping your routes to data classes (PII / PHI / cardholder data / none) so the auditor can verify the redaction configuration matches reality.

Further reading

• Secure-by-default— what the core enforces without any opt-in.
• Supply-chain security — the controls behind the SOC 2 CC6.8 / ISO A.8.7 / NIS2 21(2)(d) rows above.
• SECURITY.md — SLAs, GHSA evidence pattern, reporting flow.
• Aikido: cloud compliance frameworks overview — broader background on the frameworks themselves.