Start here
Start with the problem, not the service.
A buyer stopped the deal. An auditor left a list nobody owns. A vulnerability went public. A release is blocked and no one can say by what. The service follows from which of those you are living with.
Describe your situation↗
A customer’s security requirements are holding up the sale.
An enterprise customer sent a security questionnaire, a supplier assessment or a set of contractual security requirements. The product is good. Nobody on the team can answer in the form the buyer needs, and the deal is waiting.
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.
A vulnerability in your product is public, and your customers are asking.
A researcher, a disclosure programme or a national authority has published. Your customers read the advisory before you finished writing the answer. What happens in the next two weeks decides whether this costs you a patch or a contract.
Your imaging archive may be reachable from the internet.
Independent research has repeatedly found unprotected PACS and DICOM endpoints exposing hundreds of millions of medical images, often with patient identifiers burned into the files. The cause is almost never an exotic attack. It is a system connected directly to a public network because that was the fastest way to make it work.
An audit or penetration test returned findings nobody owns.
The report lists symptoms in the order the tooling produced them. Nothing indicates which findings share a cause, which are already satisfied, and which do not apply. Meanwhile the list is treated as a backlog of equal items, and it does not move.
A technology decision is being made on the strength of the word, not the problem.
Cloud. Kubernetes. AI. A platform migration. The technology gets chosen before anyone establishes whether this problem needs it. Sometimes it genuinely does. Often the same outcome was available at a fraction of the operating cost. The organisation then carries the difference every month, for years: a demolition hammer bought to drive a nail, and then staffed.
Architecture and ownership have drifted, and change has become expensive.
Platforms have multiplied, boundaries moved without a decision, and temporary exceptions now operate as permanent architecture. Every change costs more than the last one, and no single person can describe the whole system with confidence.
Another shape
If yours is a different shape, describe it
Architecture, platform, due diligence and delivery leadership are all in scope. A situation without a name on it is still worth describing.
Send the context↗