Notifications
Clear all
Topic starter
20/08/2026 6:01 pm
TL;DR: Cybersecurity third-party risk management is failing where questionnaires stop and real access begins, according to Strac, because vendor risk is defined by what data and systems a third party can actually reach, not what it claims in a security review. Programs that do not map blast radius, assess controls, and monitor continuously will keep underestimating breach impact.
NHIMG editorial — based on content published by Strac: Cybersecurity Third-Party Risk Management: 2026 Guide
By the numbers:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%).
Questions worth separating out
Q: How should security teams assess third-party cyber risk beyond questionnaires?
A: They should measure real access first.
Q: Why do third-party vendors create identity and access risk?
A: Because many vendors require persistent access to systems, data, or APIs, which makes them part of the trust boundary.
Q: What breaks when shadow AI is not included in identity governance?
A: When shadow AI is excluded, the organisation loses discovery, ownership, and enforcement at the same time.
Practitioner guidance
- Map vendor blast radius to data and identity pathways Identify which datasets, production systems, OAuth scopes, API keys, and service accounts each third party can touch, then tier reviews by that actual reach.
- Replace questionnaire-only reviews with access-based evidence Require logs, permissions snapshots, and credential inventories that show how the vendor authenticates and what it can reach today, not just what it claimed in onboarding.
- Bring shadow AI under third-party governance Inventory unsanctioned AI tools that handle company data, then route them through the same approval, review, and offboarding workflow used for high-risk vendors.
What's in the full article
Strac's full article covers the operational detail this post intentionally leaves at the governance layer:
- How its data-layer approach identifies which vendors and AI tools can reach sensitive records in practice
- What review signals it uses to spot shadow tools that escaped normal procurement and security assessment
- How continuous monitoring changes when vendor access, breach status, or data reach shifts over time
- Why the module ties third-party risk to DSPM and DLP workflows instead of questionnaire scoring alone
👉 Read Strac's guide to cybersecurity third-party risk management and data reach →
Third-party cyber risk: what data reach means for IAM teams?
Explore further
20/08/2026 6:39 pm
Data reach is the real third-party risk control. Security questionnaires remain useful for screening, but they do not measure the thing that determines impact: what the third party can actually reach. That means vendor governance must move from claims-based review to access-based review, especially where SaaS, APIs, and machine credentials intersect. Practitioners should treat data reach as the primary risk unit, not the vendor name or contract tier.
A question worth separating out:
Q: Who is accountable when a vendor breach exposes downstream client data?
A: Accountability is shared, but control ownership sits with the institution that granted access and the vendor that held it. Frameworks such as NIST Cybersecurity Framework 2.0 and identity governance programmes expect organisations to know their access boundaries and response responsibilities. If the access path was not governed, the incident becomes an accountability gap as well as a security one.
👉 Read our full editorial: Cybersecurity third-party risk management is really data reach
