ISO 27001 and SOC 2 Type II do not solve identity risk

At a glance

What this is: Unosecur frames ISO 27001:2022 and SOC 2 Type II as trust signals for its identity security posture, while also acknowledging that compliance attestation does not remove operational identity risk.

Why it matters: IAM, IGA, PAM, and NHI teams should treat audit artefacts as evidence of control design and operating effectiveness, not as substitutes for proving real-world identity governance under load.

👉 Read Unosecur's post on ISO 27001 and SOC 2 Type II for identity security

Context

This article is about the gap between certification and actual identity risk management. ISO 27001 and SOC 2 Type II can show that controls exist and have been assessed, but they do not by themselves prove that identity governance will hold across cloud environments, service accounts, API keys, or human access paths.

For identity programmes, that distinction matters because the hardest failures are operational, not documentary. A platform can satisfy audit expectations and still leave unanswered questions about least privilege, logging fidelity, offboarding, and whether access decisions remain trustworthy when cloud and non-human identities are in scope.

Key questions

Q: What breaks when ISO 27001 and SOC 2 are treated as proof of identity security?

A: They prove that controls exist and have been assessed, but they do not prove that identity access, telemetry, and revocation still work correctly in live environments. The failure is assuming attestation equals operational resilience. Identity teams still need to test entitlement drift, audit completeness, and offboarding effectiveness in production.

Q: Why do compliance certifications not eliminate cloud identity risk?

A: Because cloud identity risk comes from how access is granted, used, logged, and removed over time. Certifications can show governance maturity, yet they cannot stop privilege creep, weak credential lifecycle management, or gaps in monitoring when human and non-human identities change faster than review cycles.

Q: How should teams validate whether an identity platform is actually secure?

A: They should test live enforcement of least privilege, credential revocation, and identity telemetry across the environments the platform protects. A certificate is useful context, but the real test is whether access decisions remain correct when cloud roles, service accounts, and workloads change.

Q: What should IAM and IGA teams prioritise after a vendor shows ISO 27001 and SOC 2 Type II?

A: They should prioritise operational evidence over badge collection. That means checking whether the vendor can demonstrate current access boundaries, reviewable audit trails, and effective offboarding for both human and non-human identities before accepting compliance claims as sufficient.

Technical breakdown

What ISO 27001 and SOC 2 Type II actually prove

ISO 27001:2022 certification and SOC 2 Type II are assurance mechanisms, not runtime security guarantees. ISO 27001 focuses on whether an information security management system exists and is governed, while SOC 2 Type II evaluates control design and operating effectiveness over a period of time. That means they can support trust in process maturity, auditability, and control discipline, but they do not automatically validate every identity decision made in production. In identity security, the real question is whether the programme continues to enforce access boundaries when cloud roles, service accounts, and telemetry pipelines change faster than audit cycles.

Practical implication: treat both attestations as inputs to due diligence, then test identity controls directly in production.

Why identity risk persists after compliance attestation

Identity risk persists because certification does not remove the mechanics that attackers and misconfigurations exploit. Cloud access still depends on accurate entitlements, timely revocation, strong authentication for machine and human identities, and logs that capture the right events. If any of those elements drift, the organisation can remain technically compliant while still being exposed to privilege creep, weak offboarding, or hidden access paths. This is especially relevant where service accounts, API keys, and delegated cloud roles are managed across multiple environments and teams.

Practical implication: verify entitlement hygiene, credential lifecycle, and audit log completeness as separate control tests.

Zero trust requires verified identity signals, not just certificates

Zero trust depends on continuous trust evaluation, not on a static assurance badge. A certificate can show that governance exists, but zero trust still needs current identity telemetry, contextual access decisions, and evidence that permissions match the task at hand. In practice, the governing control plane must be able to prove who or what is acting, what it is allowed to do, and whether that privilege is still justified. That is why identity security vendors often use certifications as a governance baseline while still needing operational controls that stand up to live access decisions.

Practical implication: align zero-trust design with live identity signals, not with certification status alone.

Threat narrative

Attacker objective: The objective is to exploit the gap between documented control assurance and actual identity governance so access can be misused without immediate detection.

1. Entry occurs through identity misuse or control drift rather than through a failure of the certifications themselves, because the core issue is whether access paths are still governed in production.
2. Escalation follows when privileges, audit trails, or trust assumptions no longer match the real cloud environment, allowing access to persist beyond its intended scope.
3. Impact is the loss of confidence that identity controls are actually preventing misuse, even when the organisation can still present compliance evidence.

Breaches seen in the wild

• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certification is an assurance layer, not a substitute for identity governance: ISO 27001 and SOC 2 Type II can validate that a security programme is documented and independently assessed, but they do not prove that cloud identity decisions are correct at runtime. The practical implication is that practitioners must separate audit readiness from access assurance and treat them as different governance problems.

Identity risk survives compliance when entitlement drift is untested: The failure mode is not the absence of policy, but the gap between policy and live permission state across service accounts, API keys, and human access. That gap matters because IAM and IGA programmes are only as strong as the revocation, review, and telemetry controls that keep pace with operational change.

Zero trust only works when trust signals are current: A certificate can support procurement confidence, but it cannot replace contextual access decisions, continuous telemetry, or task-scoped authorization. The implication for the market is clear: certification will increasingly be treated as table stakes, while runtime identity evidence becomes the differentiator for security teams.

Control attestation and control resilience are not the same thing: A platform can pass an examination period and still fail under production pressure if identity governance depends on static assumptions about access, logging, or segregation. Practitioners should interpret attestations as proof of control design maturity, then demand evidence that those controls still operate when identities, cloud scope, and workloads change.

Identity assurance is becoming a procurement requirement, not a marketing claim: Buyers are moving from asking whether a vendor has certifications to asking whether the vendor can prove least privilege, lifecycle governance, and auditability for both human and non-human identities. That shift raises the bar for IAM and NHI evaluation and makes operational evidence more important than credentials on paper.

What this signals

Control attestation is becoming the floor, not the finish line: Security and identity buyers are increasingly treating ISO 27001 and SOC 2 as evidence of governance maturity, then asking harder questions about how access is actually enforced in production. That shift pushes IAM teams to prove runtime assurance, not just document control design.

For identity programmes, the audit story and the operational story must now be separated: A platform can satisfy an auditor while still leaving unresolved questions about entitlement drift, offboarding, and logging fidelity. The practical consequence is that procurement, risk, and engineering teams need shared tests for live identity behaviour, not just policy review.

For practitioners

• Test production identity controls separately from audit evidence Validate whether access enforcement, logging, and revocation still work in live cloud workflows, not just in attestation documents.
• Review entitlement drift across human and non-human identities Check whether service accounts, API keys, and user roles still match approved access scopes after recent operational changes.
• Verify telemetry completeness for identity events Confirm that access approvals, privilege changes, and authentication events are captured in a way that supports investigation and certification evidence.
• Separate compliance review from runtime assurance Use ISO 27001 and SOC 2 findings as governance inputs, then add production testing for least privilege, offboarding, and audit trail integrity.

Key takeaways

• ISO 27001 and SOC 2 Type II help establish that an organisation has governance and assessed controls, but they do not by themselves eliminate identity risk.
• The central issue for practitioners is whether access, telemetry, and revocation remain reliable when real cloud operations change faster than audit cycles.
• IAM, IGA, PAM, and NHI teams should use certifications as evidence of baseline control maturity, then validate live enforcement separately.

Key terms

• ISO 27001: An international information security management standard designed to create an auditable and certifiable security programme. It requires documented scope, controls, and evidence that processes are operating consistently. For NHI governance, it pushes teams to prove that machine identities are inventoried, reviewed, and retired on a repeatable schedule.
• Soc 2 Type II: A SOC 2 Type II report evaluates whether a service provider’s controls operate effectively over a defined period. In identity and access contexts, it matters because it shows evidence of real control execution, not just the existence of policy language or intent.
• Identity Assurance: The confidence an organisation has that a person or system is truly who it claims to be before access or action is granted. In modern IAM, assurance depends on evidence quality, channel trust, and the strength of verification around high-risk decisions.
• Runtime Identity Verification: Runtime identity verification is the process of proving a workload's identity at the moment access is requested rather than trusting a pre-stored secret. It ties access decisions to the current workload instance, which is more suitable for ephemeral services and short-lived sessions.

What's in the full article

Unosecur's full blog covers the certification and security posture details this post intentionally leaves at the governance level:

• The specific claims Unosecur makes about its ISO 27001:2022 and SOC 2 Type II milestones
• The way Unosecur describes its cloud identity security and ITDR positioning
• The customer-facing trust language the vendor uses to connect certifications with operational security
• The FAQ framing around identity management, zero trust, and multi-cloud access assurance

👉 Unosecur's full blog covers the certification details and customer-facing security claims in more depth.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.