Who should be accountable for making sure certified practitioners are actually ready to work on identity programmes?

Why This Matters for Security Teams

Certification can signal baseline knowledge, but it does not prove that a person is ready for a specific identity programme, environment, or operating model. The real risk sits with the organisation that assigns work, grants access, and accepts the outcome. That is especially true when the role touches production directories, privileged workflows, or lifecycle controls where mistakes can create lasting exposure.

NHIMG research shows how quickly identity risk becomes operational risk: the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. Those figures matter here because “certified” still does not mean “fit for this assignment.” Security leaders should treat certification as one input alongside supervision, scoped access, and role validation. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls also reinforces that access, oversight, and accountability must be operationally enforced rather than assumed.

In practice, many security teams discover readiness gaps only after a certified practitioner has already been placed into a sensitive identity function and made a costly control decision.

How It Works in Practice

Accountability should be placed with the organisation that controls assignment, supervision, and access review. In a mature model, that means the line manager, programme owner, or service owner confirms the practitioner is ready for the exact scope of work, not just generally qualified. Certification can support trust, but it should never replace task-specific validation.

Good practice is to break readiness into observable checks:

• Verify the certification maps to the actual platform, control set, or identity domain being operated.
• Confirm the practitioner has recent hands-on experience, not only exam completion.
• Use peer review or shadowing for changes that affect privileged access, JIT workflows, or production identity systems.
• Reassess access after role changes, incidents, or long gaps away from the environment.
• Document who approved the assignment and who is responsible for ongoing oversight.

This approach aligns with the control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls, where accountability is tied to enforced processes, not credentials alone. It also fits the operational reality described in the 52 NHI Breaches Analysis, which shows how access and governance failures compound when ownership is unclear. For identity programmes, the practical test is simple: if the work can alter authentication, entitlement, or secret handling, the organisation assigning the work owns the risk.

These controls tend to break down in fast-moving delivery teams where identity work is outsourced, split across vendors, or assigned informally without a named approver.

Common Variations and Edge Cases

Tighter assignment controls often increase delivery overhead, requiring organisations to balance speed against assurance. That tradeoff becomes most visible when teams rely on contractors, joint ventures, or global delivery models where certification is used as a procurement filter rather than an operational readiness check.

There is no universal standard for this yet, but current guidance suggests three patterns:

• For low-risk advisory work, certification may be enough for initial screening, provided the organisation still reviews scope and supervision.
• For production identity engineering or privileged administration, certification should be supplemented with role-based assessment, access approval, and post-assignment review.
• For regulated or high-impact environments, the accountable party should be explicitly named in the engagement terms, not left implicit.

One common mistake is assuming the certifying body carries responsibility for competence in a specific environment. It does not. Another is letting the customer assume oversight exists when the supplier never documented it. NHIMG’s Ultimate Guide to NHIs shows why this matters: only 5.7% of organisations have full visibility into their service accounts, which means weak practitioner readiness can quickly become weak identity governance. In practice, readiness must be proven by the organisation placing the practitioner into the role, especially when the work touches access lifecycle, secret handling, or privileged change control.

Related resources from NHI Mgmt Group

• Who is accountable for making sure onboarding programmes produce job-ready security practitioners?
• Who should be accountable for improving identity security readiness across universities, employers, and training programmes?
• Why do dynamic, context-based access policies work better than static groups for modern identity governance?
• Who is accountable for protecting identity data when access is granted across partners and internal business units?