EU compliance for app makers in 2026: CRA, accessibility, NIS2, GDPR

The short version: four regimes, one readiness plan#

Four EU rule sets matter for most software teams in 2026: the Cyber Resilience Act (CRA) for security of products, the European Accessibility Act (EAA) for consumer-facing services, NIS2 for cybersecurity of essential and important entities and their supply chains, and GDPR for personal data. They overlap more than they differ, so one readiness plan covers most of the ground.

Cyber Resilience Act: reporting applies now#

Under the Cyber Resilience Act, reporting of actively exploited vulnerabilities and severe incidents applies from 11 September 2026, and the full set of obligations follows on 11 December 2027. If your product is in scope, the reporting part is already live, so you need to be able to detect, assess and report an exploited vulnerability today.

Reporting is only possible if you know what is in your product, how people can tell you about a flaw, and who does what when one is found. That is three artefacts: a software bill of materials, a vulnerability disclosure policy and an incident runbook.

If parts of your product were written with AI assistants, assume vulnerabilities exist that nobody has looked for yet. Our production checklist for vibe-coded apps and Supabase RLS checklist cover the most common ones.

Generate an SBOM in CI

A software bill of materials lists every component and version your product ships. Generate it automatically on every release in a standard format such as CycloneDX or SPDX, store it with the release, and scan it for known vulnerabilities.

# Node.js example: CycloneDX SBOM for the production dependency tree
npx @cyclonedx/cyclonedx-npm --omit dev --output-file sbom.cdx.json

# Scan the SBOM for known vulnerabilities (e.g. with Grype)
grype sbom:./sbom.cdx.json --fail-on high

Publish a vulnerability disclosure policy and security.txt

Give researchers and customers one clear way to report a flaw: a short disclosure policy page and a security.txt file at /.well-known/security.txt (RFC 9116) that points to it. Use a monitored shared mailbox, not a person's inbox.

Contact: mailto:security@example.com
Expires: 2027-10-01T00:00:00.000Z
Preferred-Languages: en, sk, cs
Policy: https://example.com/security/disclosure-policy
Canonical: https://example.com/.well-known/security.txt

Write the incident runbook before you need it

A runbook turns a stressful night into a sequence of steps. It should say who is on call, how severity is decided, how to contain and restore, who decides whether something is reportable and to whom, and how evidence and timelines are recorded. Have counsel confirm the reporting deadlines and channels that apply to you, then write them into the runbook.

• [ ]SBOM generated automatically for every release and stored with it
• [ ]Dependency and container scanning in CI, with a policy for fixing high-severity findings
• [ ]Vulnerability disclosure policy published; security.txt live and not expired
• [ ]Coordinated disclosure contact: shared mailbox, monitored, with an acknowledgement template
• [ ]Incident runbook with named roles, severity levels and a reporting decision step
• [ ]Timestamped incident log kept from the first alert (needed for any report)
• [ ]Process to ship security updates to users quickly and tell them what changed

European Accessibility Act: web apps and stores#

The European Accessibility Act has applied since 28 June 2025, mostly to consumer-facing services such as e-commerce, banking, transport, e-books and telecoms. Service micro-enterprises are exempt. The technical benchmark is EN 301 549, which broadly corresponds to WCAG 2.1 AA; building to WCAG 2.2 AA gets you there with margin.

If you sell to consumers through a web app or mobile app, assume accessibility is now a product requirement, like security. Even where the act does not apply to you, accessible interfaces are easier to use, test and automate.

• [ ]Automated checks (for example axe) in CI on key pages, failing the build on new violations
• [ ]Full keyboard navigation with visible focus on every interactive element
• [ ]Screen-reader pass on the critical paths: sign-up, search, checkout, account settings
• [ ]Colour contrast meets AA for text and UI components, in light and dark themes
• [ ]Forms have labels, clear error messages and do not rely on colour alone
• [ ]Target sizes and focus behaviour meet the WCAG 2.2 additions
• [ ]Motion respects prefers-reduced-motion; no content flashes
• [ ]An accessibility statement and a way for users to report barriers

NIS2 in Slovakia and Czechia#

NIS2 is already national law in both countries: Slovakia transposed it by amending Act 69/2018, and Czechia adopted a new Cybersecurity Act in 2025. Whether your own company is in scope is a legal question. If your clients are in scope, you will feel it anyway, because they must manage supply-chain risk and will ask their software suppliers for evidence.

In practice that evidence looks like the CRA list above plus a few organisational items. Prepare it once and reuse it for every security questionnaire.

• Access control. Named accounts, multi-factor authentication, least privilege, offboarding within a day.
• Audit logs. Who did what, when, on production systems and admin panels.
• Encryption. In transit everywhere; at rest for databases and backups.
• Backups with restore tests. A backup you have never restored is a hope, not a control.
• Documented incident response. The runbook above, with contact paths to the client.

None of this requires a certificate. Being SOC 2 or ISO 27001 ready (logs, access control, encryption, backups, documented incident response) answers most supplier questionnaires.

GDPR Article 28: sign the DPA#

When a vendor processes personal data on your behalf, GDPR Article 28 requires a written data processing agreement (DPA) between you. That applies to your hosting, email, analytics and support tools, and to the agency that builds or maintains your app if it can access production data.

• [ ]A list of every processor that touches personal data, with what data and why
• [ ]A signed DPA with each of them, including your development and maintenance partner
• [ ]Sub-processors listed, with a way to be notified of changes
• [ ]Data minimised in non-production environments: no raw production dumps on laptops
• [ ]Breach notification duties between you and each processor written into the DPA

Common gaps in small teams#

The gaps that cause trouble are rarely exotic. They are ordinary engineering habits that were skipped while the product was being built quickly, and they show up the first time a client sends a security questionnaire or a researcher sends an email nobody answers.

• Nobody owns security mail. Reports go to a former employee's inbox or a contact form that nobody triages.
• Dependencies are years old. Upgrading feels risky because there are no tests, so known vulnerabilities stay in production.
• Secrets live in the repository. API keys in code or in client-side bundles, often copied from an AI-generated example.
• No logs worth the name. When something happens, there is no way to say what was accessed and by whom.
• Accessibility was never tested. Custom components look right but cannot be reached with a keyboard or read by a screen reader.
• Contracts lag behind reality. New tools were added to the stack without a DPA, and the sub-processor list is out of date.

Each of these is cheap to fix once and expensive to discover during an incident. If your app was assembled fast, a structured review such as the one in rescue, refactor or rewrite helps decide where to start.

A 90-day readiness plan#

Most teams can reach a defensible baseline in about a quarter if they treat compliance as engineering work with owners and deadlines. Order matters: start with what is already legally live (CRA reporting, EAA), then build the evidence clients will ask for.

1. Weeks 1–2: confirm scope with counsel; inventory products, processors and personal data; publish security.txt and a disclosure policy.
2. Weeks 3–4: SBOM and dependency scanning in CI; write and rehearse the incident runbook once.
3. Weeks 5–8: WCAG 2.2 AA audit of critical paths; fix blockers first; add automated accessibility checks to CI.
4. Weeks 9–10: sign or update DPAs; tighten access control, MFA and audit logging.
5. Weeks 11–12: restore test from backup; collect the evidence pack (policies, SBOMs, audit results, runbook) in one place.

Regulators and enterprise clients ask for the same thing: proof that you know what you ship and what you do when it breaks.

How Backloo can help#

We can set up this baseline as part of a build or a care plan: SBOMs in CI, a disclosure contact, an incident runbook, audit logs and WCAG 2.2 AA interfaces. Our maintenance and SLA care plans keep dependencies patched and the evidence current, and our websites are built to WCAG 2.2 AA from the start.

We sign a GDPR Article 28 DPA with every client whose personal data we can access. If you want to know where an existing app stands, a Rescue Audit gives you a written view of the security gaps. We are engineers, not lawyers, so we work alongside your counsel. Contact us with questions.