EmberKat
Problems/Evidence is assembled after the fact

Your buyers require security evidence your delivery process does not produce.

Per-release security reports, an SBOM, vulnerability decisions, signed artefacts, a documented disclosure route. Right now these are assembled by hand under deadline pressure, if at all. From 11 September 2026 the Cyber Resilience Act makes one of these a legal duty rather than a buyer preference: reporting an actively exploited vulnerability. The bill of materials and the release evidence follow on 11 December 2027.

Indicative range
Typically €12,000–25,000, scoped after review
Shape
Usually four to eight weeks, remote.

What you are already seeing

  • Security documentation is produced for an audit, then goes stale until the next one.
  • Nobody can say what is in a given release without rebuilding the answer.
  • Each large customer imposes slightly different supplier requirements.
  • There is no agreed route for someone outside the company to report a vulnerability.

What gets examined

  1. 01

    What evidence your buyers and the applicable regulation actually require, and by when.

  2. 02

    Which of it the pipeline could emit automatically and currently does not.

  3. 03

    Where vulnerability decisions are made, and whether anyone records the reasoning.

  4. 04

    Whether the disclosure and reporting route would survive being used under time pressure.

What you are left holding

  1. 01

    A delivery process that emits its own evidence, per release.

  2. 02

    A vulnerability triage rule set with recorded decisions rather than a scanner dump.

  3. 03

    A documented disclosure and reporting route with named responsibilities.

  4. 04

    A gap list against the obligations that apply to your products, sequenced by deadline.

Before you send anything

Plain language is enough — the system, who owns the outcome, and the date that matters. Keep confidential reports, credentials and production data out of a first message; a secure exchange route is agreed before any of it moves. Indicative ranges are exactly that: the scope, exclusions and price are confirmed in a written proposal before work starts.

From the glossary

SBOMSoftware Bill of Materials
A list of every component inside a piece of software — an ingredients label, in a form a machine can read.
The full glossary

Next step

Describe the situation

A short reply confirms whether this is the right shape of work, what inputs are needed, and what it would cost.

Send the context