A public intake
An intake page and a security.txt file, so a report has a front door that is not one person's email.
CRA evidence
CRA vulnerability handling your own team can run for years
A clear path from "someone reported a bug" to a recorded decision, a fix and an advisory, for the whole support period.
Checked against the regulation on 16 Oct 2026 · What changed
One fixed price, in writing, the same day you ask · a delivery date agreed in writing · about 4 hours of your engineers' time · the price only changes if the scope does.
NDA before anything sensitive · the drill runs on sample data · no production access · every document is yours.
In your own tools · Your team runs it · We do not become the security team
What the CRA asks
A contact point, a decision on the record, and fixes without delay when a fix is what you chose.
The CRA asks for a disclosure policy and a contact point that is not limited to automated tools. Fixes are to be provided without delay. Security updates are free, and they come with advisories. Not every vulnerability needs a patch, but the decision must be written down.
That path has to last the support period, not just the week after launch. A report that arrives in a personal inbox, with the decision living in a chat, will not survive a question about it a year later.
What we build
From the public contact to the advisory, with a hand-off when a case is actively exploited.
Triage
States and response targets that you set.
Decision records
Owner and evidence for the decision, including a decision not to patch.
Fix to release
A fix is mapped to the release that carries it, so you can say which version has it.
Advisory drafts
A draft advisory for the update. Your team publishes it.
Hand-off
When a case is actively exploited, it hands off to the reporting desk and the Article 14 clocks.
The path
An actively exploited case leaves this path and opens on the reporting desk.
- Intake
- Triage
- Decision
- Fix mapped to a release
- Advisory
If the case is actively exploited, it branches to the reporting desk.
In use
A report gets a state, a decision, and either a release or a written reason.
A report arrives on the intake page. Triage gives it a state. Someone records the decision and the evidence. If there is a fix, it is mapped to a release and an advisory is drafted. If the case is actively exploited, it moves to the reporting desk.
How it works
We write the path into the tools you already use.
Call
How a report reaches you today.
Brief
States, targets, and who is allowed to decide.
Build
Intake, records, and the hand-off to reporting.
Launch
One practice report, on sample data.
Handover
Code, docs and access are yours. We stay on call for 30 days.
What you get, and what we need
You get a path with a record. We need the people who will use it.
What you get
- A public contact and a security.txt file.
- Triage states and the targets you set.
- Decision records, with owner and evidence.
- Fixes mapped to releases, and advisory drafts.
What we need from you
- Who triages, and who can decide not to patch.
- The support period you publish.
- The inbox or tracker reports should land in.
- Your adviser, if a policy template needs adapting.
Related
Questions
Will you run our security team?
No. We set up the path and the records. Your people triage, decide and fix. You stay responsible.
Will you write our disclosure policy?
We give a template for your team or adviser to adapt. We do not sign it, and it is not legal advice.
Must we patch every vulnerability?
Not every vulnerability needs a patch. The decision does have to be documented, with an owner and the evidence behind it.
Is this a PSIRT?
In practice, yes. A PSIRT is the team and process that receives, triages and answers vulnerability reports. We set up that process and its records, sized for a small product team.
Samisoftz builds the process and software your team uses to organise CRA evidence and reporting. You stay responsible for meeting the regulation. We don't give legal advice, act as a notified body, or submit reports for you.
On a delivery date agreed in writing, your team will know who decides, what to send at 24 and 72 hours, and will have practised it once on your own product. The decision to report stays with you. We set up how.
Could your team send a 24-hour early warning tomorrow? Find out in 30 minutes.
You'll talk to Usama, who'd build it.
30 minutes · no slides · a written answer if it's not a fit
One fixed price, in writing, the same day you ask · a delivery date agreed in writing · about 4 hours of your engineers' time · the price only changes if the scope does.
NDA before anything sensitive · the drill runs on sample data · no production access · every document is yours.