On 29 October 2026, developers using Cursor’s extension marketplace received what looked like a routine update to the official Claude Code extension. Once activated, the modified build tried to add an attacker’s SSH key, open a reverse tunnel, and send host details to an external server. It stayed available for about 11 hours before Cursor removed it, temporarily shut down the marketplace, and told users to rotate any credentials reachable from affected machines (Cursor, October 2026). A supplier owned the trusted channel, and the code ran on engineers’ laptops. But an assessment limited to the systems a company runs itself would never have rated that marketplace. Our threat intelligence write-up covers the attack chain in detail.
Many teams run a careful security risk assessment of the systems they operate and treat suppliers as a separate, lighter exercise. Below is a process you can run this quarter, with six steps grounded in NIST guidance, a template structure to copy, and a way to carry the same rigor to the vendors who hold your data.
What is a security risk assessment?
A security risk assessment is a structured review of the assets an organization depends on, the threats and vulnerabilities that could affect them, and the likelihood and business impact of each scenario. Its output is a ranked list of risks with a decision recorded against each one, whether to mitigate, transfer, avoid, or accept. NIST SP 800-30 Rev. 1, the guide most programs borrow from, frames the assessment as one input to ongoing risk management.
Scope usually spans identity and access, endpoints, applications, cloud configuration, physical sites, and the data flows between them. A vulnerability assessment scans for technical flaws, and a security audit checks controls against a standard. The risk assessment weighs the findings of both against business impact and tells you which one deserves the budget.
What are the steps in a security risk assessment?
Most teams run six steps: define scope and inventory assets, identify threats and vulnerabilities, rate likelihood and impact, decide how to treat each risk, document and report the results, and monitor until the next review. The sequence maps to the prepare, conduct, communicate, and maintain phases in NIST SP 800-30, so the output holds up when an auditor or regulator asks how you reached your ratings.
- Scope and inventory. List the systems, data stores, and business processes in scope, including every vendor that stores, processes, or can reach your data. A vendor missing from the inventory is a risk nobody will rate.
- Identify threats and vulnerabilities. For each asset, name realistic threat events, such as credential theft, ransomware, or a supplier compromise, and the weaknesses that would let them succeed. Scan results, penetration tests, threat intelligence, and questionnaire answers all count as evidence.
- Rate likelihood and impact. Score each scenario on a defined scale, for example, 1 to 5, and write down what each level means so two analysts would land on the same number. Impact should describe business consequences such as downtime, data exposure, and reporting duties.
- Decide the treatment. Mitigate, transfer, avoid, or accept. Every accepted risk needs a named owner who signed the decision.
- Document and report. Record each rating, the evidence behind it, and the decision. Leadership needs the top risks and their direction of travel, while the people fixing them need the specifics.
- Monitor and reassess. Track remediation to closure and define the events that reopen a rating before the next scheduled cycle.
What should a security risk assessment template include?
A good template is a risk register with enough columns to show how each rating was reached. At minimum, record the asset or vendor relationship, the data and access involved, the threat scenario, the evidence and its date, likelihood, impact, existing controls, the treatment decision, an owner, a due date, and the event that would force a re-rating.
| Field | What to record |
|---|---|
| Asset or relationship | The system, process, or vendor, with its business owner |
| Data and access | Data types handled and the access path (network, API, credentials) |
| Threat scenario | Who or what, doing what, with what result |
| Evidence | Scan findings, test results, questionnaire answers or certifications, each dated |
| Likelihood and impact | Scores on your scale, plus one line of reasoning |
| Treatment and owner | The decision, the named owner and a due date |
| Review trigger | The event that reopens the rating, such as a renewal, a supplier incident, or end of support |
Dating the evidence matters more than it looks. A SOC 2 report from last year and an external scan from this morning carry different weight, and the register should show which one a rating rests on. For vendor question sets, see our third-party assessment template.
How do you extend a security risk assessment to third parties?
Treat each vendor that stores, processes, or can reach your data as an asset in scope. Tier vendors by the data and access they hold, collect evidence in proportion to that tier, check their externally visible security posture, map the suppliers they depend on, and set triggers that reopen the rating when something changes. The same register then shows internal and third-party risk side by side.
Verizon’s 2025 Data Breach Investigations Report found that a third party was involved in 30% of breaches, double the prior year’s share (Verizon, April 2025). The Cursor incident shows how quickly that exposure moves. An annual review of the marketplace, however thorough, would have said nothing useful on 29 October. What helps on a day like that is knowing which teams use the tool and what their machines can reach, so you know whose credentials to rotate first.
Four practices carry the assessment past your own perimeter:
- Tier by data and access, ahead of spend. A low-cost messaging tool that can reach your customers may carry more risk than a large facilities contract.
- Match evidence to the tier. Critical vendors get a full questionnaire, supporting documents, and an external posture review, while low-tier vendors may need only the external check. Our vendor risk assessment guide covers the tiers in detail.
- Look past the direct vendor. Ask which hosting, software, and support providers sit behind each critical supplier, because fourth-party risk reaches you through them.
- Watch between reviews. Continuous monitoring of external posture and cyber news lets a supplier incident reopen the rating in the week it happens.
How often should you run a security risk assessment?
Run a full assessment at least once a year, and reassess between cycles when something material changes, such as a new system or vendor with access to sensitive data, a merger, a major architecture change, a supplier breach, or an end-of-support notice. Regulated firms should check their own obligations too. Under DORA, fully applicable since January 2025, EU financial entities must keep a register of ICT third-party providers and conduct risk assessments.
Cadence can follow the tiers. Critical vendors and crown-jewel systems may justify a quarterly look, and low-risk relationships can wait for the annual cycle, provided monitoring would flag a change in between.
Where third-party cyber risk management fits
Third-party cyber risk management (TPCRM) is the discipline of running that vendor step continuously across every supplier relationship. Its central idea is context. An external finding means one thing for a vendor that hosts customer records and something else for one that delivers office supplies. Contextual risk scoring weighs a vendor’s security posture against the data, access, and business process the relationship involves, so each rating reflects your exposure to that supplier.
So the relationship becomes the unit of assessment. Two companies can rely on the same supplier and carry very different risk from it, depending on what each has connected. A practical test for any program is whether the register can answer one question for any vendor in the news, namely what this supplier holds of ours and what we do now.
For more on running the vendor side of this work, read our guide to third-party risk management.
Security Risk Assessment FAQs
Who should conduct the assessment?
The security or GRC team usually leads, with system owners, IT, legal, and procurement supplying evidence and context. Business owners should rate impact, since they know what an outage or data exposure would cost their function. Some organizations bring in an external assessor for independence, often ahead of an audit or certification, while keeping the risk decisions and their ownership inside the business.
How is a risk assessment different from a vulnerability assessment?
A vulnerability assessment finds technical weaknesses, such as missing patches or exposed services, usually with scanning tools. A risk assessment takes those findings, along with threats, controls, and business context, and estimates likelihood and impact to decide what to fix first. A vulnerability scan is one source of evidence, and the risk assessment turns that evidence into a ranked list of decisions.
Which frameworks guide security risk assessments?
NIST SP 800-30 Rev. 1 sets out the assessment process itself. NIST CSF 2.0, released in February 2024, added a Govern function that includes supply-chain risk governance. ISO/IEC 27005 gives risk management guidance for organizations running an ISO/IEC 27001 program, and FAIR offers a model for estimating risk in financial terms. Most teams borrow the process from one framework and the control set from another.
How do you assess a third party’s security?
Start with what the vendor holds, meaning the data, the systems it can reach, and the business process it supports, and set the depth of review from that tier. Combine a questionnaire with supporting documents, such as SOC 2 reports or ISO/IEC 27001 certificates, an external view of the vendor’s attack surface, and a check of its own key suppliers. Then monitor for changes and incidents between formal reviews.
What happens after the assessment?
Each risk gets a treatment decision, an owner, and a due date, and leadership receives a summary of the top risks and their trend. Accepted risks are signed off. From then on, the register stays live, and ratings reopen when a trigger fires, such as a new vendor or a supplier incident.
