Access Reapproval and Recertification

Why Access Reapproval and Recertification Matters
Access control decisions are not permanent. Users change roles, projects end, contractors leave, and systems evolve. Yet access rights granted months or years ago often remain in place long after they are needed. This phenomenon, known as privilege creep or access accumulation, is one of the most common root causes of insider misuse, data breaches, and audit findings. A user who moved from Finance to Marketing may still be able to approve payments; a developer who left the project may still hold production database credentials.

Access reapproval and recertification exist to address this gap. They are the periodic, formal processes by which an organization confirms that every granted access right is still justified, still appropriate for the user's current role, and still authorized by the right owner. For a CSSLP, this topic sits within the Secure Software Requirements domain because the software you build must support these processes: it must capture who has what access, expose that data to reviewers, allow revocation, and log the outcome. If a system cannot answer the question "who has access to what, and who approved it?", it cannot be recertified, and that is a requirements failure, not merely an operations problem.

Regulatory and framework drivers reinforce the importance: SOX (Sarbanes-Oxley) requires periodic review of access to financial systems; PCI DSS requires reviews of user accounts and access privileges; HIPAA requires workforce clearance and access authorization procedures; ISO/IEC 27001 (A.5.18 in the 2022 edition) calls for regular review of access rights; and NIST SP 800-53 control AC-2 requires account review at an organization-defined frequency. Auditors routinely ask for evidence of these reviews, so the software must produce that evidence.

What Access Reapproval and Recertification Are
Although often used interchangeably, the two terms carry subtly different emphases, and the exam may test that nuance:

Access Recertification (also called access review, attestation, or entitlement review) is the periodic, scheduled process in which a designated reviewer, usually a line manager, data owner, or application owner, examines a list of users and their entitlements and formally attests that each one is still appropriate. The reviewer either confirms (certifies) the access or flags it for removal. It is proactive and calendar-driven: quarterly, semi-annually, or annually, with higher-risk access reviewed more frequently.

Access Reapproval is the act of re-authorizing access that is about to expire or that has been called into question by a trigger event. Many organizations grant access with a built-in expiry date; before that date, the owner must actively reapprove it or the access lapses automatically. Reapproval is therefore closely tied to time-bound access, sunset provisions, and event-driven reviews (role change, transfer, project completion, policy violation).

The practical distinction: recertification asks "Is everything currently granted still correct?" across a population, while reapproval asks "Should this specific access continue past its expiry or trigger point?" Both aim at the same outcome: enforcing least privilege and need-to-know over time, not just at the moment access is first granted.

Key Terminology You Must Know

Entitlement: a specific right or permission a user holds (a role, group membership, permission flag, or privilege).
Attestation: the formal act by which a reviewer declares that access is appropriate; it creates an accountability record.
Privilege creep / entitlement accumulation: the gradual accrual of rights beyond current job needs.
Orphaned account: an account whose owner has left or whose business justification no longer exists.
Dormant account: an account not used for a defined period, a strong candidate for removal.
Segregation of Duties (SoD) conflict: a combination of entitlements that lets one person both perform and approve a sensitive action; recertification must detect these.
Rubber-stamping: the failure mode in which reviewers bulk-approve without genuine scrutiny, undermining the entire control.
Revocation / deprovisioning: the removal of access following a negative certification decision.
Compensating control: an alternative control accepted when access with an SoD conflict cannot be removed for business reasons.

How Access Reapproval and Recertification Work

1. Define Scope and Frequency Based on Risk
Not every system needs the same cadence. Privileged accounts (administrators, service accounts with elevated rights, database owners) and access to regulated or highly sensitive data are typically reviewed quarterly or more often. Standard business application access may be reviewed semi-annually or annually. The requirement specification should state the frequency, the systems in scope, and what triggers an off-cycle review (termination, transfer, role change, security incident).

2. Establish Ownership
Every application, data set, and role must have a named owner accountable for approving and recertifying access. Line managers typically certify that their direct reports still need access; data or application owners certify that the entitlements themselves are appropriately scoped. Without clear ownership, reviews stall or default to IT staff who lack the business context to judge appropriateness.

3. Collect and Correlate Entitlement Data
The system under review must be able to export or expose a complete, accurate, and current list of users and their entitlements. This is where secure software requirements become concrete. The application must store access data in a queryable form, map technical permissions to business-meaningful roles, include metadata (who granted the access, when, under what justification), and integrate with identity governance tools via standard interfaces (SCIM, LDAP, APIs). Correlating accounts to real identities in the HR system is essential to detect orphaned accounts.

4. Present Reviewable Information
Reviewers must see access in understandable terms. A manager cannot sensibly certify "GRP_FIN_AP_L3_RW"; they can certify "Accounts Payable – approve invoices up to $50,000." Good requirements call for human-readable role descriptions, last-login dates, risk indicators, flagged SoD conflicts, and changes since the last review (delta reviews reduce fatigue and rubber-stamping).

5. Make Decisions
The reviewer certifies, revokes, or modifies each entitlement. Many programs also allow "escalate" or "delegate" for cases where the reviewer lacks knowledge. Decisions must be captured with the reviewer's identity, timestamp, and any justification.

6. Remediate
Revocation decisions must actually be executed, ideally automatically through provisioning connectors, with verification that the access was removed. A review that identifies excess access but never removes it provides little security benefit and fails audits. Requirements should specify the maximum time between decision and enforcement.

7. Evidence and Reporting
The entire campaign must be logged in a tamper-evident manner: who was reviewed, who reviewed, what was decided, when, and what remediation occurred. Completion rates, overdue reviews, and revocation rates are tracked as metrics. This evidence is what satisfies auditors and demonstrates due diligence.

8. Handle Non-Response
Policy must define what happens when a reviewer does not respond by the deadline. The secure default is fail-safe: unreviewed access is revoked or suspended rather than silently continued. Escalation to the reviewer's manager is common before automatic revocation.

Translating This into Software Requirements
As a CSSLP, you are expected to turn this process into testable requirements during the requirements phase. Examples include:

- The system shall maintain a record for each access grant including grantor, grantee, entitlement, justification, grant date, and expiry date.
- The system shall support time-bound access that expires automatically unless reapproved by the designated owner.
- The system shall provide an export of all user entitlements in a documented format to support periodic recertification.
- The system shall record all access review decisions in an append-only audit log.
- The system shall flag accounts with no authentication activity in 90 days.
- The system shall identify entitlement combinations defined as segregation-of-duties conflicts.
- The system shall revoke access within 24 hours of a revocation decision and confirm completion.
- The system shall provide role-based views so that managers see only their direct reports' entitlements.

These requirements are traceable to regulatory drivers, support the principle of least privilege, and enable the operational control to function. They should be captured as both functional requirements (the features) and non-functional requirements (performance of exports, integrity of logs, availability of review interfaces).

Relationship to Other CSSLP Concepts
Access recertification sits at the intersection of several principles you must recognize on the exam:

Least privilege: recertification is the mechanism that maintains least privilege over time.
Separation of duties: reviews detect toxic combinations; the reviewer should not be the person who benefits from the access.
Accountability and non-repudiation: attestation records create accountability for access decisions.
Fail-safe defaults: unreviewed or expired access should default to denied.
Complete mediation: every access should be authorized, and recertification confirms the authorization is still valid.
Identity lifecycle management: recertification is the "review" stage in the joiner-mover-leaver (provision, modify, deprovision) lifecycle, with movers being the highest-risk population for privilege creep.
Auditability: the software must produce evidence; this is a core secure requirement.

Common Pitfalls
Rubber-stamping by overloaded reviewers; reviewing accounts but not the specific entitlements; failing to include service, shared, and privileged accounts; disconnecting the review from actual revocation; relying on manual spreadsheets that cannot be audited; reviewing too infrequently for high-risk access; and designing software that cannot export or explain its own access model. Each of these is a likely source of exam scenario questions.

Exam Tips: Answering Questions on Access Reapproval and Recertification

Tip 1: Identify the principle being tested. Most questions on this topic ultimately test least privilege over time. If a scenario describes a user who changed roles and retained old permissions, the problem is privilege creep and the control is periodic recertification (plus event-triggered review on role change).

Tip 2: Know who should perform the review. The correct reviewer is the business owner of the data or application, or the user's manager, because they have the context to judge business need. If an answer choice says the IT help desk, the security team alone, or the user themselves should certify their own access, treat it with suspicion. Self-certification violates separation of duties.

Tip 3: Frequency follows risk. If asked how often to recertify, the best answer ties frequency to the sensitivity of the access: privileged and regulated access more frequently (often quarterly), general access less frequently (annually or semi-annually). Avoid answers suggesting a single fixed frequency for everything or review only at initial provisioning.

Tip 4: Distinguish reapproval from recertification when the question demands it. If the scenario involves access with an expiry date or a trigger event such as a transfer, the term is reapproval (re-authorization of specific access). If it involves a scheduled campaign reviewing all users and entitlements, the term is recertification or access review.

Tip 5: Fail-safe is the default. When a reviewer does not respond, the secure answer is to revoke or suspend access (after escalation), not to leave it in place. Questions about expired access that "should remain until someone objects" describe an insecure design.

Tip 6: Remember that the CSSLP perspective is about requirements. When a question asks what the software team should do, the best answer typically involves building the capability into the system: maintaining entitlement records, supporting time-bound access, logging review decisions, enabling exports or integration with identity governance tools, and providing automated revocation. Answers that put the entire burden on manual operational procedures are generally weaker than answers that embed support in the software.

Tip 7: Review must lead to action. If a scenario describes a completed review that identified excess access, the next required step is remediation (revocation) and verification. A review without enforcement is incomplete; an answer that stops at "document the findings" is usually not the best one.

Tip 8: Watch for scope omissions. Scenarios that mention only employee accounts may be testing whether you remember privileged accounts, service accounts, shared accounts, contractors, and third-party access, all of which must be in scope.

Tip 9: Map to regulations when the question cites one. SOX implies financial systems and SoD; PCI DSS implies cardholder data environments; HIPAA implies workforce access to PHI. The common thread is that each requires periodic access review and auditable evidence.

Tip 10: Eliminate absolute or technology-only answers. Options that claim automation alone solves recertification, or that reviews are unnecessary if provisioning is strong, ignore the reality of changing roles. Equally, options that rely solely on manual spreadsheets ignore auditability and scale. The best answers combine clear ownership, risk-based frequency, human-readable data, documented decisions, automated enforcement, and retained evidence.

Summary
Access reapproval and recertification keep authorization aligned with reality. Access granted correctly on day one becomes excessive as people and systems change; periodic, owner-driven, evidence-producing reviews with real revocation are the countermeasure. For the CSSLP, the essential insight is that these controls depend on software that was designed to support them: systems that record who has what and why, present it understandably, allow time-bound and reapprovable grants, enforce revocation, and log everything immutably. Capture these as explicit secure software requirements, trace them to regulatory and policy drivers, and in the exam, anchor your answers to least privilege, business ownership, risk-based frequency, fail-safe defaults, and auditable remediation.