Periodic risk assessments evaluate the control environment, likely threats, and governance gaps across the program. Access certification focuses on whether specific users still need the access they hold and whether that access remains appropriate. Both are necessary, but they answer different questions: one tests overall security posture, while the other validates entitlement legitimacy and supports removal of unnecessary access.
Why GLBA Uses Two Different Control Questions
Periodic risk assessments and access certification both support GLBA compliance, but they operate at different layers of control. A risk assessment asks whether the program is designed and operating effectively against current threats, control gaps, and governance weaknesses. Access certification asks whether a given person still needs their access and whether that access is still appropriate for the role they perform.
That distinction matters because GLBA programs usually fail in two different ways: one is weak oversight of the control environment, the other is stale or excessive access that no one revisits. The first is a program-level assurance question. The second is an entitlement-level hygiene question. Treating them as substitutes leaves one of those failure modes untested.
For program context, Ultimate Guide to NHIs is useful because it shows how access governance, lifecycle controls, and visibility problems become material when credentials and accounts are left unreviewed. For control design, the ISO/IEC 27002:2022 Information Security Controls guidance helps frame the broader governance and access-control discipline behind periodic review, while the CIS Controls v8 reinforce account management and access governance as operational safeguards.
What Periodic Risk Assessments Actually Test
A periodic risk assessment is broad by design. It evaluates whether the institution’s controls still match its risk profile, whether threat assumptions have changed, and whether governance gaps have emerged since the last review. In practice, that means looking across assets, processes, third parties, monitoring, change management, and control ownership rather than focusing on one access list or one user population.
In GLBA terms, the value of the assessment is that it can expose weaknesses that an access review would never surface, such as incomplete asset inventories, inadequate segregation of duties, weak exception handling, or control drift after business changes. It is also the mechanism that tells you whether the access-review process itself is still frequent enough, scoped correctly, and tied to actual business risk.
That broader lens is why a risk assessment is not just a compliance exercise. It is the place where you validate the assumptions behind the whole program, including where sensitive customer information resides, who can reach it, and which control failures would create material exposure. The question is not “does this user still need access,” but “is the organisation still adequately controlling the environment in which access exists?”
What Access Certification Actually Tests
Access certification is narrower and more concrete. It asks managers or data owners to review current entitlements and confirm whether each user, account, or role still has a business need for the access they hold. The result should be a keep, reduce, or revoke decision, with exceptions documented and tracked to closure.
This is where entitlement legitimacy is tested. If the review is done well, it catches dormant accounts, job-function drift, orphaned access after transfers, and permissions that were granted for a short-term need but never removed. The control is especially important where customer data, financial records, and administrative functions are involved, because the question is not just whether access exists, but whether continued access is justified.
Practitioners often understate the difference between review and remediation. Certification creates evidence that someone looked at access, but compliance value only materialises when reviewers have the authority, context, and follow-through to remove unnecessary access. A signed review with no revocation workflow is documentation, not control effectiveness.
For a practical governance lens, NHI Lifecycle Management Guide and Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs illustrate why lifecycle review matters when access and ownership change over time. For external control mapping, ISO/IEC 27001:2022 Information Security Management and CIS Controls v8 both support the underlying expectation that access must be governed, reviewed, and corrected when it no longer matches need.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | GLBA access certification maps to reviewing and removing unnecessary access. |
| 5 — Account Management | Periodic risk assessments and certification both depend on knowing which accounts exist and who owns them. | |
| Recommendation — Review account access regularly and revoke entitlements that no longer have a business need. Maintain an accurate account inventory and ownership record before running certification cycles. | ||
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Periodic risk assessments are a core governance activity for aligning security controls to changing risk. |
| PR.AA — Identity Management, Authentication and Access Control | Access certification is part of ensuring access remains appropriate and controlled over time. | |
| Recommendation — Use a documented risk-management process to reassess control effectiveness as the environment changes. Validate that only appropriately authorised users retain access and remove excess entitlements promptly. | ||
| ISO/IEC 42001:2023 | AI Management System | No material AI-management-system alignment is present in this GLBA access-review distinction. |
| Recommendation — Omit. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The question is about GLBA control roles, not identity-proofing or authenticator requirements. |
| Recommendation — Omit. | ||
Practitioner Guidance
Decision rule: Use periodic risk assessments to test whether the control environment still matches the institution’s GLBA risk profile; use access certification to test whether specific access grants are still justified. If the issue is “how good is the program?”, start with the risk assessment. If the issue is “who still needs this access?”, start with certification.
What to verify: The review should have a defined population, an accountable reviewer, a documented exception path, and a completed remediation trail. If access is certified but not actually removed when rejected, the control failed at the operational stage, even if the paperwork looks complete.
What practitioners underestimate: These controls are complementary, not interchangeable. A strong risk assessment can coexist with excessive access, and a thorough access review can coexist with a weak control environment. GLBA compliance is strongest when both are working together, one at the program level and one at the entitlement level.
Practitioner takeaway: Treat the assessment as a posture test and the certification as an entitlement test; GLBA expects both because each catches a different class of failure.
Related resources from NHI Mgmt Group
- What is the difference between continuous compliance and periodic access certification?
- What is the difference between access certification and segregation of duties analysis in access governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
