Threat Modelling
Find out how a system could be attacked while it is still on the whiteboard. You get a threat model, prioritised mitigations in your backlog and a method your engineers can reuse.
Service Details
Threat modelling shows you how a system could be attacked while it is still a design, so your engineers can build the right defences in before code ships. You get a clear map of your data flows and trust boundaries, a ranked list of threats, and agreed fixes that land in your backlog rather than a report nobody reads.
Changing a diagram is far cheaper than reworking a live system, which is why we do this work at design stage. It sits within our assessments and engineering services, alongside the testing and engineering work that checks those designs once they are built.
INFO
Every engagement answers four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job.
Design security in, don't bolt it on
Every system has an attack surface. The question is whether your team finds the weak points first, or someone else does.
We start from your architecture as it is actually designed: components, data flows, trust boundaries and third-party dependencies. Then we work through, element by element, how each part could be misused, and what would stop it.
Methods we use to find what can go wrong
Proven techniques, chosen to suit your system:
Data Flow Diagrams
A shared picture of components, data stores, external parties and the trust boundaries data crosses between them.
STRIDE Analysis
Each element checked for spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
Attack Trees and PASTA
Attacker goals broken into the steps needed to reach them, with risk-led analysis where business impact drives priority.
LINDDUN and MITRE ATT&CK
Privacy threats such as linkability and identifiability, plus threats grounded in techniques real attackers are known to use.
Who threat modelling is for
Threat modelling suits teams building or changing something: a new product, a customer-facing application, a cloud migration, or an integration that moves sensitive data between systems. It is most useful when the design is settled enough to draw but not yet fixed in code.
It also helps when you have inherited a system nobody fully understands. Modelling it gives you an accurate picture of how data moves and where the trust boundaries really sit, which is the starting point for any sensible security work.
How a threat modelling engagement runs
We work inside your delivery process, with your architects and engineers, using your diagrams and tools. Each step maps to one of the four questions.
- Scope and diagram — Together we agree what is in scope and draw the data flows, components and trust boundaries. This answers “what are we working on?”.
- Identify threats — We work through each element with STRIDE and the other methods that fit, rating every threat by likelihood and impact. This answers “what can go wrong?”.
- Agree mitigations — Each threat gets a decision: fix, reduce, transfer or accept, with an owner and priority. This answers “what are we going to do about it?”.
- Review and revisit — We check mitigations have landed and the model still matches the system, then agree when to update it. This answers “did we do a good job?”.
What you keep after the engagement
The threat model is a working document, not a one-off report. You keep everything needed to act on it and to repeat the exercise for the next change.
Threat Model
Diagrams, threats per component and risk ratings in one document
Mitigation Backlog
Tickets with owners and priorities, ready for your sprint planning
Reusable Method
Templates and guidance so your architects can model future changes
How it differs from related services
Threat modelling focuses on the design of one system. Architecture and design shapes the overall structure of your estate, and a threat model then tests specific designs within it. Penetration testing attacks what has been built, to prove whether weaknesses are exploitable in practice.
Application security covers the code and testing of individual applications, while product security looks after a product across its whole life. Threat modelling feeds both, by telling them where the design risks are.
Evidence for audits and regulators
Threat models are useful evidence that security was considered at design stage. ISO 27001 expects a secure development life cycle and secure engineering principles, and UK GDPR Article 25 requires data protection by design. The NIST Secure Software Development Framework names threat modelling as a practice directly. Our compliance support team can map your models to the controls your auditor checks.
Services that work alongside
Threat modelling pairs well with CI/CD security, so the controls you design are enforced in your build pipeline. For systems using machine learning, AI and ML security covers threats specific to models and training data. Findings that affect the wider business feed into risk management, and cloud engineering can build the mitigations into your cloud platform.
Frequently asked questions
Model it before you build it
Tell us about the system you are designing or changing next. You get a clear view of how a threat modelling session would run, who needs to be in the room and what your team walks away with.