Service · fixed fee

A working Article 14 reporting process, before the clock starts

From 11 September 2026, EU-market software must report exploited vulnerabilities in 24h. I build the intake, runbook and workflow in 10 days.

From , manufacturers selling software or connected products in the EU must report actively exploited vulnerabilities within 24 hours (Reg. (EU) 2024/2847, Art. 14). I build the intake channel, the triage runbook and the reporting workflow — an operating process with a rehearsed dry-run — for $2,500 fixed in 10 working days.

$2,500 fixed· 10 working days

Half on start, half on delivery of the evidence pack. Milestone billing above $8,000. Evidence pack or no fee: every engagement ends with a dated evidence pack. If I don’t deliver it, you don’t pay the closing half.

Email the deskFull price ladder →

What is this for, exactly?

Manufacturers of products with digital elements on the EU market — obliged to report actively exploited vulnerabilities from 11 September 2026.

What do you get?

  • A vulnerability intake channel: /.well-known/security.txt, a disclosure policy, a monitored inbox
  • A triage runbook with severity criteria and the “is it actively exploited?” decision
  • The reporting workflow: 24-hour early warning, 72-hour full notification, final report within 14 days of a corrective measure — routed via the CRA Single Reporting Platform to your CSIRT
  • Named roles, a contact list, and one rehearsed dry-run

Why is “a process, not a document” the whole product?

A reporting policy PDF does not answer a 24-hour clock. What answers it is: a route for the world to tell you about a vulnerability (/.well-known/security.txt, a disclosure policy, a monitored inbox), a triage step that decides “is this actively exploited?”, named people who know it is their job, and a workflow that has been run once before it is run for real. That is what gets built, and the dry-run at the end is what proves it works.

What is the cheapest honest test of your exposure?

Open yourdomain/.well-known/security.txt. If it returns a 404, there is currently no published route for a researcher to report a vulnerability to you — which means the 24-hour clock can start without you knowing. That single check is free, takes ten seconds, and is exactly how I find most of the companies I write to. This site's own security.txt and disclosure policy are live — the artefact I sell, deployed where you can inspect it.

Where do the reports actually go?

Once, through the CRA Single Reporting Platform, addressed to the CSIRT of your main establishment — with the information made available to ENISA. The workflow encodes the route, the timelines (24 hours / 72 hours / 14 days, one month for severe incidents) and the content each stage needs, per the Commission's published guidance (European Commission, “CRA reporting obligations”, retrieved ).

What does the price not include?

Stated before you ask, because a fixed price is only fixed if its edges are published.

  • No legal advice on whether your product is in scope
  • No ongoing monitoring retainer — the process is yours and runs without me
  • Discovery tooling (SBOM, dependency scanning) is configured from your existing stack; new tooling licences are yours

Which deadlines does this answer?

  1. upcomingCyber Resilience Act — Article 14 reporting
  2. upcomingCyber Resilience Act — full application

Questions buyers actually ask

Is this the whole CRA? We keep hearing about CE marking and SBOMs.

No — and that distinction is the point. The CRA's full essential requirements apply from 11 December 2027. What bites on 11 September 2026 is Article 14: the duty to report actively exploited vulnerabilities and severe incidents. That needs a working process, not a conformity programme.

We have a security team. Why would we need outside help for this?

Many teams can build this themselves — the gap is usually that nobody has. If you already have an intake channel, a triage runbook with the “actively exploited?” decision, named roles and a rehearsed dry-run, you don’t need me. If those exist only as intentions, ten working days turns them into an operating process.

What actually has to happen within 24 hours?

An early warning to the CSIRT of your main establishment, submitted through the CRA Single Reporting Platform, within 24 hours of becoming aware of an actively exploited vulnerability. The full notification follows within 72 hours, and a final report within 14 days of a corrective measure — one month for severe incidents. The process I set up encodes those clocks with named owners.

Does this include ongoing monitoring or an SBOM?

No. Article 14 requires you to be able to discover, decide and report — so the engagement configures discovery from your existing stack (dependency scanning, a disclosure channel) and builds the decision and reporting workflow. A full vulnerability-management programme is a different, larger engagement, and I will say so rather than blur the line.

Can you file reports on our behalf?

The process is built so your named people can file within the deadlines — that is deliberately not outsourced to a supplier in a different timezone. What you get is the channel, the runbook, the workflow and one rehearsed dry-run, so the first real report is not also the first attempt.

Last reviewed· Every dated claim on this page links to its source.

Which obligation is closest?

Tell me the deadline you are looking at and what your site does. You get a straight answer about whether it applies to you, and a fixed price if it does.

Email the deskSee every date

Direct to hello@sophura.com · one person, named, who answers. I don’t give legal advice.