If you run API 780 assessments, I’d value your view
If you carry out, commission or review security risk assessments to API 780, including the new Second Edition, this post is for you.
HawkSight is a security risk management platform in production today, built on ISO 31000. We’ve now built a proof of concept that takes the same platform, the same interface and the same way of working, and runs it on the API 780 Second Edition method instead. Before we invest further and take it into production, we need to know one thing from the people who actually do this work. Would it be valuable to you?
This year I delivered API 780 Second Edition training to Saudi Aramco. It reinforced something we’ve believed for a while. The method is sound. The harder part is running it consistently, at volume, and keeping it current once the report goes out.
Have you seen the API 780 Second Edition?
API published the Second Edition of STD 780 in 2026, replacing the 2013 edition. If you haven’t worked through it yet, the good news is that the method you know is still there. This is refinement, not a rewrite.
The changes worth knowing about include:
- It is now a full API Standard with clear conformance language, while still allowing customised methods that follow its five steps.
- Nation-state actors join the list of threat sources.
- The edition names open-source information, social media and AI-generated information as sources to draw on.
- Crediting existing countermeasures now rests on a formal set of tests rather than general principles.
- The threat assessment steps are simpler, and the definition of residual risk is clearer.
Cyber and information security sit firmly inside the method, with information systems or automation expertise expected on the SRA team.
For anyone revisiting an SRA programme under the new edition, it is a natural moment to ask a practical question. Is the way we run these assessments still fit for purpose?
When the method isn’t the problem
Some organisations I’ve come across need to carry out dozens of security risk assessments every quarter. At that volume, the method is rarely what holds them back. Capacity is.
Trained API 780 analysts are scarce, and much of their time goes on gathering, collating and formatting rather than on the judgement the standard relies on. Meanwhile, many assessments still live in spreadsheets, Word templates and shared drives. Each one is a snapshot that starts ageing the day it goes out, and the next one often starts from a blank page.
You can’t run API 780 through an ISO 31000 tool
We learned this first-hand. We built HawkSight on ISO 31000, and it works well for organisations managing security risk across sites, portfolios and domains. But when we looked closely at API 780, it was clear that you can’t reach an API 780 assessment by running it through an ISO 31000 framework.
In short, ISO 31000 tells you how to think about risk. API 780 tells you what to score, in what order, and how to show the result.
| ISO 31000 | API 780 | |
|---|---|---|
| Nature | Principles and framework | Prescribed assessment method |
| Scope | Any risk, any organisation | Security risk at petroleum and petrochemical facilities |
| Adversary | One risk source among many | Threat and attractiveness assessed explicitly |
| Consequence | Criteria set by the organisation | Worst credible outcome across defined categories |
| Controls | Effectiveness evaluated | Effectiveness shown by re-scoring vulnerability |
| Output | Risk register and treatment plan | Structured, repeatable, auditable assessment |
A tool built on one framework forces analysts to bend the other to fit. For a standard that values a defensible, step-by-step audit trail, that defeats the point.
One platform, two frameworks
So we asked a different question. What if the platform stayed the same, and only the framework changed? Our proof of concept keeps everything HawkSight users already rely on, including the interface, the risk libraries, the reporting and the audit trail. Underneath, the workflow follows API 780’s own five-step structure rather than ISO 31000’s adapted to fit. The aim is more assessments, done more accurately, without more headcount.
More efficient. Reusable libraries of assets, threats and countermeasures mean teams aren’t rebuilding the same scenarios at every facility. Likewise, a revalidation starts from the last assessment, not an empty form.
More accurate. Every assessor, on every site, applies the worst-case consequence rule, the screening steps and the before-and-after vulnerability comparison in the same way. Scores carry forward and are never retyped, and every one keeps its rationale, its author and its date.
AI-assisted, not AI-decided. HawkSight Nexus, the AI orchestration layer launching on our platform in early 2027, would do the heavy lifting for a trained analyst:
- Gathering open-source information, which the Second Edition now recognises, with every source cited and a stated level of confidence
- Drafting threat narratives covering history, capability and intent, ready to edit for the specific site
- Flagging scores that look out of line with similar assets elsewhere in the portfolio
- Drafting the security overview and the report
Consequence, vulnerability and how well a control actually works remain human judgements. The analyst accepts, edits or rejects every suggestion before it moves on, and the platform records every decision. Nexus suggests. The assessor decides.
We need your view
HawkSight is already in production on ISO 31000. The decision in front of us is whether to put an API 780 Second Edition version into production alongside it, so we offer the platform in two frameworks. That depends on you.
If you work with API 780, I’d be grateful if you could tell me:
- Roughly how many API 780 assessments do you carry out or commission each year?
- How do you run them today, and where does the work live afterwards?
- Would a dedicated API 780 version of a proven risk platform, with AI assistance, be valuable to you?
- If it existed, what would it absolutely need to do?
Tell me in the comments on the LinkedIn post, or email me directly at paul@hssrm.com if you’d rather not share publicly. I’ll arrange a walkthrough of the proof of concept.
Every answer helps, including “not for us”. After all, it is exactly what we need to know before deciding whether this is worth building.