Technology and SaaS.
When your product is the system, your customers inherit your risk, and their procurement teams will ask you to prove you have measured it. An assessment often has to serve two audiences at once, your own engineering roadmap and your customers' due diligence.
Regulatory anchor. Enterprise procurement and assurance programmes routinely require evidence of a structured, framework-aligned risk assessment before they will buy.
Application and platform risk. Exposure assessed against the real deployment, not an idealised architecture diagram.
Supply chain and dependencies. Risk across the build pipeline and the third-party code the product rests on.
Findings engineering will act on. A register that maps onto a backlog rather than sitting in a policy binder.
What we assess that is specific to it.
The method does not change. What changes is what we look hardest at, and what counts as a serious result.
What counts as severe here.
Impact is calibrated to the sector. The same threat carries a different weight depending on what it would actually cost.
| Rating | What it means in this sector |
|---|---|
| Severe | Compromise of customer data or a core platform, with contractual and reputational consequences across the customer base. |
| Major | Significant service disruption or a breach requiring customer notification. |
| Moderate | Contained impact absorbed without customer-visible effect. |
What the report has to survive.
A technology report has two readers with different needs: your own engineers, who need findings that map onto a backlog, and your customers' security reviewers, who need evidence they will accept. It has to be concrete enough to action and rigorous enough to hand to a procurement team without a caveat.
Working in technology?
Tell us what you run and what you need to decide. We will tell you plainly whether we are the right people for it.