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

At a glance

What this is: Unosecur says its ISO 27001:2022 and SOC 2 Type II milestones validate security governance for its cloud identity platform.

Why it matters: For IAM practitioners, the real question is whether independent attestations map to the identity risks that matter across NHI, autonomous, and human access programmes.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

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

Context

ISO 27001 and SOC 2 Type II are assurance signals, not identity controls. They tell practitioners that a provider has documented governance, operational discipline, and audit evidence, but they do not by themselves prove how well the platform handles service accounts, API keys, or cloud identity telemetry in live environments.

For identity programmes, that distinction matters. A cloud identity platform can be well governed and still sit on top of unresolved NHI, IAM, and access-review problems inside the customer environment, which is why certification should be read as a baseline for trust rather than a substitute for control validation.

Key questions

Q: How should security teams use ISO 27001 and SOC 2 when evaluating cloud identity providers?

A: Use them as baseline assurance evidence, not as proof that the platform eliminates identity risk. ISO 27001 and SOC 2 Type II tell you that controls, governance, and audit processes exist and were tested. They do not replace your own validation of service account lifecycle, token handling, logging, and access review quality.

Q: Why do certifications matter for non-human identity governance?

A: They matter because NHI governance depends on disciplined control execution around secrets, entitlements, audit trails, and incident response. A certified provider is more likely to have repeatable processes, but the customer still owns whether credentials are scoped correctly, rotated on time, and removed when no longer needed.

Q: What should teams verify beyond vendor certification claims?

A: Verify the actual control evidence. Ask for lifecycle logs, access review artefacts, audit trail samples, and incident handling detail for the identities you rely on. If the provider cannot show how the platform behaves during credential changes or offboarding, the certification is only a trust signal.

Q: How do certifications fit into zero trust architecture?

A: They support trust establishment, but zero trust still requires continuous verification at runtime. For identity security, that means checking whether authentication, authorisation, and logging stay reliable as access changes across cloud services, workloads, and administrators.

Technical breakdown

What ISO 27001 and SOC 2 Type II actually prove

ISO 27001 checks whether an organisation runs an information security management system with documented risk treatment, while SOC 2 Type II evaluates whether stated controls operated effectively over time. Neither framework certifies product security in the abstract. Instead, they show that a provider can evidence control design, monitoring, and auditability around its own environment and processes. For identity security buyers, this is useful but incomplete because the hardest failures often sit in entitlement sprawl, token exposure, and offboarding gaps that the provider’s attestations cannot eliminate inside your tenancy.

Practical implication: use the attestations as a procurement baseline, then test the platform’s identity controls against your own NHI and IAM requirements.

Why certifications matter to NHI governance

Non-human identity governance depends on visibility, lifecycle control, and evidence that privileged access is managed consistently across cloud services. Certifications help show that the vendor has repeatable controls around data handling, logging, change management, and incident response, which can support trust in the platform that governs service accounts and API keys. But NHI risk is still determined by how access is issued, rotated, reviewed, and revoked in practice. A certified provider can still leave customers exposed if the customer’s operating model allows standing privilege, weak secrets hygiene, or poor credential offboarding.

Practical implication: align the platform’s assurances with your own lifecycle, rotation, and review processes before treating it as identity-safe.

How zero trust changes the meaning of assurance

Zero trust depends on continuous verification, not on a one-time claim that a system is secure. That is why certifications help more with trust establishment than with runtime authorisation. In cloud identity security, the control question is whether identity telemetry, audit trails, and context-aware decisions remain reliable when access patterns change across tenants, clouds, and workloads. A certified provider may still need to prove, in your environment, that the platform can support policy enforcement without blind spots in machine identity or autonomous access paths.

Practical implication: verify that certification evidence is paired with telemetry, audit, and contextual access controls in production.

NHI Mgmt Group analysis

Certification is a governance signal, not a control outcome. ISO 27001 and SOC 2 Type II show that the vendor can evidence process maturity, but they do not prove that identity threats are contained in customer environments. For cloud identity buyers, that means the assurance layer sits above the operational risk layer, not inside it. Practitioners should treat the certifications as a prerequisite for trust assessment, not as proof that access pathways are safe.

NHI trust still depends on lifecycle execution, not audit language. A platform can be independently reviewed and still fail where service accounts, API keys, and tokens are created, rotated, and retired. The meaningful question is whether the operating model can actually prevent standing privilege and stale secrets from persisting across cloud environments. That is the control surface identity teams must validate.

Identity assurance debt: independent attestations reduce vendor due-diligence friction, but they do not repay the debt created when runtime identity controls remain untested in customer workflows. This is especially visible in cloud identity platforms that claim coverage across human and non-human access. The implication is that security teams must separate trust in the provider from trust in the identities the provider governs.

Zero trust demands runtime evidence, not certification alone. Certifications can support procurement and governance reviews, but they do not satisfy the need for continuous identity verification, telemetry fidelity, and auditable enforcement. In practice, the field is moving toward proof of control execution rather than proof of control intent. Practitioners should insist on operational evidence at the point of access.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
• For a broader baseline on non-human identity governance, see Ultimate Guide to NHIs , Key Research and Survey Results for how organisations are measuring control gaps.

What this signals

Identity assurance debt: certification evidence lowers procurement friction, but it does not close the gap between documented controls and runtime behaviour. In cloud identity programmes, that gap is where stale secrets, standing privilege, and incomplete offboarding continue to create exposure, so practitioners should treat vendor attestations as one input among several, not as a control endpoint.

The practical signal for IAM teams is that assurance needs to be tested against actual workflow evidence, not only policy statements. If a provider cannot show how access changes are logged, reviewed, and revoked across tenants, the certification tells you about governance maturity, not about the identities you are responsible for.

The clearest next step is to align assurance checks with recognised standards such as the NIST Cybersecurity Framework 2.0 and, where applicable, sector obligations like the EU NIS2 Directive, because identity security programmes fail when procurement trust and operational trust are conflated.

For practitioners

• Map certification scope to identity controls Confirm whether ISO 27001 and SOC 2 coverage includes the specific environments, processes, and support boundaries that matter to your NHI and IAM programme. Do not assume a platform-wide attestation covers every tenant workflow or every privilege path.
• Validate service account lifecycle controls Ask how the platform handles creation, rotation, review, and offboarding for service accounts, API keys, and tokens. Require evidence that lifecycle events are logged and reviewable rather than inferred from policy language alone.
• Test auditability under real access changes Run a sample review that follows one identity from provisioning to privilege change to revocation, then verify that the audit trail remains intact across cloud environments. This shows whether the control model survives operational drift.
• Separate provider assurance from programme assurance Use certification evidence for vendor due diligence, but maintain your own access reviews, secrets governance, and telemetry validation for the identities you operate. A certified platform does not remove the need for internal control ownership.

Key takeaways

• ISO 27001 and SOC 2 Type II confirm governance maturity, but they do not prove that identity risk is eliminated in live cloud environments.
• The most persistent identity failures still happen in lifecycle execution, secrets handling, and auditability, where certifications cannot substitute for control validation.
• Practitioners should treat vendor attestations as a procurement filter and then test runtime identity controls against their own NHI and IAM requirements.

Key terms

• Information Security Management System: A structured set of policies, roles, processes, and controls used to manage information security risk. In practice, it shows whether security is operated as a repeatable management system rather than as an ad hoc collection of tools and incidents.
• Soc 2 Type II: An assurance report that evaluates whether a provider's stated controls operated effectively over a period of time. It is useful for due diligence, but it does not certify that every customer workflow or identity path is secure in real-world use.
• Identity Assurance: The degree of confidence that an identity, its credentials, and its access decisions can be trusted for the intended use. For cloud and NHI programmes, assurance depends on lifecycle control, auditability, and evidence of consistent runtime enforcement.
• Runtime Access Control: The set of decisions and checks applied when access is actually being used, not just when it is granted. This matters because identity risk often appears after provisioning, when privileges, tokens, and telemetry must continue to behave correctly.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• How the platform maps ISO 27001 and SOC 2 Type II controls to its own internal security practices and audit scope
• The specific security domains covered by the certifications, including governance, availability, confidentiality, and incident handling
• The vendor's explanation of how these certifications relate to multi-cloud identity protection and customer trust
• The FAQ section's plain-language breakdown of certification meaning for cloud identity and NHI management

👉 Unosecur's full blog covers the certification context, FAQs, and trust implications for customers

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.