What we do for you

You answer a short set of questions about your product and get back a plain reading: whether the law reaches it, which group it falls into, which dates apply to you and what to do first. It runs on published rules rather than on a model, so the same answers always produce the same result, and the reasoning is shown next to the answer.

Nobody calls you afterwards unless you ask. If it turns out the law does not reach your product, we say so, and you have spent five minutes.

You fill in one form in your own time and give us read access to your product documentation. You get back a signed scoping memorandum: whether the law covers each product and version and why, which group it falls into and who has to check your work as a result, the dates that apply to you, how long you should support the product, and the three things to do first. The manufacturer determines the support period so that it reflects the expected time in use; it must be at least five years unless the product is expected to be used for a shorter time.[Art. 13(8)]

If your product falls into one of the stricter groups, we say so and explain what that means for you. Conformity assessment uses the modules in Annex VIII: internal control (Module A) for default products; important class I products may use internal control only when applying harmonised standards, common specifications or a certification scheme; important class II products need a third party (Modules B and C, or H).[Art. 32; Annex VIII] We are honest about one thing here: the chapter that lets the independent bodies exist applies before the main duties do, and when this page was written no body had yet been listed for this law. The chapter on the notification of conformity assessment bodies applies from 11 June 2026, so that notified bodies can be in place before the main obligations apply.[Art. 71(2); Chapter IV] If you are going to need one, it is much better to know that now than in the last quarter before the deadline.

The fee comes off in full against anything you buy afterwards.

The first thing you receive is code, not a document. We open one change against your own code that adds four things: a build step that produces a signed list of every component in the product, a check that stops the build when a dangerous component gets in, the small standard file (security.txt) that tells outside researchers where to send a security report, and a note saying how long the product is supported. Your engineers review and merge it. That merged change is the first piece of evidence in your paperwork.

The rest of it delivers:

• a published policy telling outsiders how to report a problem to you, and the person who answers; Manufacturers must put in place and enforce a coordinated vulnerability disclosure policy.[Annex I, Part II, point 5]
• a written plan for what happens when one arrives, keyed to the legal clocks and practised once with your team; For an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.[Art. 14(2)]
• a review of how updates reach your product, and of who inside your company would act on a warning about it;
• the paperwork folder in the structure the law requires, already holding the evidence produced so far;
• a draft declaration for you to complete and sign as the manufacturer.

We work with Python, Node, Java, .NET and Docker, on GitHub Actions and GitLab CI, on one product family in one repository. Anything else we quote separately rather than guess at.

"Ready to report in ten working days" is the target for the core of that list, and the ten days are ours: they do not stop while we wait for a meeting, because there are no meetings in them. We track it day by day and you see the tracker. The contract commits our effort to the target, not a guaranteed result.

Choosing and configuring the tool that watches your components is a separate job with its own price — see set up your own monitoring below.

We take a read-only copy of your code, run our scanners over it and compare what we find against the law's requirements, one by one. Products must be designed, developed and produced to meet the product cybersecurity requirements in Annex I Part I, and manufacturers must meet the vulnerability handling requirements in Annex I Part II.[Art. 13(1); Annex I] You get a plain report of what is missing, with the evidence from your own code beside each item, and a plan in priority order that separates what you need now from what you need before the second date. The raw findings and the component list come with it, so your team can start without us.

It is credited in full against getting ready for the market, so in a job that goes ahead it costs nothing. If you are a smaller firm with one product, you do not need this: the package above already tells you where the gaps are.

Every essential requirement checked against your product and closed or planned; how you build and how you ship updates written down and running; the risk assessment done; the technical file assembled in the structure the law asks for; and the declaration drafted for you to complete and sign. The manufacturer draws up the technical documentation with the content set out in Annex VII before placing the product on the market and keeps it up to date during the support period.[Art. 31; Annex VII]

• Everything you have already paid us comes off the price, in full.
• You can take it as two invoices in two budget periods if one signature is easier to get than another. It is the same total either way.
• It is priced per unit, and a unit is one product family sharing a codebase and a release train — see what one price is for.

We compare the monitoring tools that suit your stack and your size and write down which one we would choose and why. We set that tool up in an account you own and pay for, against your own component list, and route the alerts to the people in your company who would actually act on one. We give you a one-off picture of what is vulnerable in your product today, so you know what you are starting from, and one page saying what to do when an alert arrives: who is told, what they check, what the first message says, who sends it, what goes in the log. Then a short recorded walkthrough for your team, the keys, and we step back.

You own the tool and the account from that moment, and from then on you watch your own product on something that keeps working whether or not you ever hear from us again. That is the main reason to do it this way round.

What it is not. We do not watch your product. We are not sent your alerts, we owe you no response time, we run no rota and nobody here is on call, at any hour of any day. We are not a security operations centre and not an incident response service. The tool's own subscription is yours and is not included in our fee. We hold your credentials only while we are setting the tool up and give them back at hand-over. The public sources any tool reads are other people's and can be late or incomplete. You decide whether a weakness is really being exploited, you decide what to report, and you send it.

An actively exploited vulnerability is one for which there is reliable evidence that malicious code was executed by an actor on a system without the permission of the system owner; a severe incident is one that has an impact on the security of the product.[Art. 3 (definitions); Art. 14(3)]

If we recommend a particular tool, we take nothing from the company behind it. No referral fee, no commission, no partner status. We put that in writing at the same moment, and the choice is recorded in your decision log as a decision you took on our advice. What we suggest is what fits your product and your team, and there is no other reason for it to be on the list.

It is one fee, once, per unit, and the second and later units cost less, because by then it is the same tool and the same routes with a different component list.