Notifications
Clear all
Topic starter
21/08/2026 4:44 pm
TL;DR: Cybersecurity posture assessments often cover assets, vulnerabilities, policies, and compliance, but Intigriti’s guide shows that third-party risk, access controls, and training only become meaningful when organisations connect them to business context and operational evidence. The gap is not the checklist itself, but whether identity, privilege, and external exposure are measured with enough discipline to change decisions.
NHIMG editorial — based on content published by INTIGRITI: Assessing your cybersecurity posture: The processes and frameworks you need
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams include identities in cyber risk assessments?
A: Security teams should treat human accounts, service accounts, tokens, and delegated vendor access as first-class risk objects.
Q: Why do third-party integrations make posture assessments harder to trust?
A: Because delegated access often outlives the business need that created it.
Q: What breaks when access review does not cover non-human identities used by AI agents?
A: When access review ignores the NHIs behind AI agents, organisations lose visibility into stale privileges, inherited rights, and abandoned credentials that still allow action.
Practitioner guidance
- Build identity scope into posture scoping Add service accounts, API keys, tokens, certificates, and delegated OAuth relationships to the asset inventory before the assessment begins.
- Test third-party access as a live control Validate which vendors and integrations can still reach sensitive data, privileged APIs, or production workflows.
- Link findings to framework controls Map each high-risk finding to a control family in NIST Cybersecurity Framework 2.0 or NIST SP 800-53 Rev 5 Security and Privacy Controls so remediation has a named owner and measurable closure criteria.
What's in the full article
INTIGRITI's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step posture assessment checklists with concrete examples for assets, controls, and reporting.
- Guidance on selecting and applying NIST CSF, ISO 27001, COBIT 5, and PCI DSS in the assessment process.
- Practical advice on compiling findings into executive-ready reports with charts, priorities, and buy-in language.
- Examples of how to present remediation priorities to non-technical stakeholders without losing risk context.
Cybersecurity posture assessments: where identity visibility is still missing?
Explore further
21/08/2026 5:04 pm
Cybersecurity posture is increasingly an identity governance problem: the most material weaknesses are often not missing tools but unmanaged access pathways. Service accounts, API keys, OAuth grants, and vendor integrations can remain outside effective review even when the broader security programme looks mature. That means posture assessments need identity visibility as a baseline, not an optional appendix. Practitioners should treat identity scope as part of the control plane, not a separate line item.
A question worth separating out:
Q: Who is accountable when posture findings reveal unmanaged vendor access?
A: The business owner of the integration, the security team that set the control baseline, and the governance function that approved the risk all share responsibility. Accountability should be explicit before the review starts, because posture assessments only improve outcomes when findings can be assigned, tracked, and validated through closure evidence.
👉 Read our full editorial: Cybersecurity posture assessments need identity visibility, not just checklists
