The acronyms on your desk, in one sentence each

An EU law that holds organisations in important sectors — health, finance, energy, transport, digital — responsible both for their own security and for checking their suppliers.

Article 21(2)(d) is the supplier part. It is the reason hospitals and banks now send security questionnaires to the companies that sell them software.

An EU law that puts security requirements on the product itself — effectively anything containing software that is sold in the EU.

You have to know what is inside your product, handle vulnerabilities in it, and report the ones being actively exploited. Reporting duties start 11 September 2026; the rest apply from 11 December 2027.

The EU law on artificial intelligence. It sorts uses by risk and attaches obligations to the higher-risk ones.

Where a product is already regulated — a medical device, for instance — the AI Act applies on top rather than instead. Its application dates were deferred by the Digital Omnibus agreement of 7 May 2026, so check them against the published text before planning around them.

An international standard for how an organisation runs its information security — the management side, not the product.

Certification is what customers most often ask for as proof, which is also its limit: it says a system for managing security exists, not that any particular product is sound.

The EU law on personal data. Its security duties mean a breach is not only a technical failure but something the organisation has to account for.

The EU’s cybersecurity agency. Under the CRA, actively exploited vulnerabilities are reported to it.

The national body a serious security incident gets reported to. Every EU country has one.

The EU law covering medical devices, including software that is a medical device in its own right.

Annex I sections 17.2 and 17.4 are the security requirements: build to the state of the art, and protect against unauthorised access.

The equivalent of the MDR for diagnostic tests and the software that runs them.

The European Commission’s guidance on how cybersecurity should be handled for medical devices.

Not law in itself, but what an auditor expects to see followed — across the whole product life, not only before launch.

The international standard for how medical device software is developed and maintained.

It defines the stages and the records each stage has to leave behind.

The security companion to IEC 62304: which security activities belong in each stage of a health software product’s life.

Auditors treat the European version as the practical route to satisfying the MDR’s security requirements.

The independent organisation that audits a medical device and certifies it before it can be sold in the EU.

The duty to keep watching a product after it has been sold, and to act on what that watching finds.

The standard format and network language for medical images and the information attached to them.

Anything that stores, moves or displays a scan speaks it — which also makes it a route into a hospital network.

The hospital system that stores medical images and serves them to clinicians.

Often the oldest system in the building and the one holding the most data — decades of it, on patients who cannot be asked again.

Software that is itself the medical device, rather than a component inside a physical one.

A list of every component inside a piece of software — an ingredients label, in a form a machine can read.

The CRA requires a manufacturer to have one. It does not require publishing it: it belongs in the technical file and goes to authorities on request. When a customer asks for a copy, that is procurement, not law.

A statement of whether a known flaw in a component actually affects your product.

Most published flaws in a dependency are not reachable in the way a given product uses it. VEX is how that is said in a form the customer’s tooling can process, instead of being argued over email.

A public reference number for a known security flaw — like a case number that anyone can look up.

Once one is published for a component you ship, customers can find it themselves and will ask what you are doing about it.

The agreed process for handling a reported security flaw: who is told, in what order, and by when.

Having it written down before it is needed is the difference between a controlled week and an improvised one.

Where a software component came from, and whether that can be shown rather than assumed.

The formal check that a product meets its legal requirements before it is placed on the market.

The examination a buyer or investor runs before a deal, to test whether what they were told about the technology holds.

Its job is to surface what would change the price, the plan, or the decision to proceed.

Shortcuts inside a system that still work, but make every later change slower and riskier.

Like a loan: useful when taken, with interest charged on every release afterwards.

The gap that opens between how a system was designed and how it actually behaves after years of changes.

Nobody decides to have it. It accumulates from reasonable decisions taken without a current picture.

Building security checks into the ordinary process of shipping software, rather than testing at the end.

In practice the hard part is not which tool runs the check, but who owns it when the check fails and the release is due.

The automated pipeline that builds, tests and releases software every time it changes.

The line where information or control passes between parts of a system that do not trust each other equally.

Most serious findings live on one of these lines rather than inside a component.

Actually fixing what an assessment found — as opposed to recording it.