Certified: The ISC(2) ISSAP Audio Course

When authorization is treated as a one-time grant, it almost always drifts into a messy, risky state where people keep access long after they need it and where nobody can confidently explain why a permission exists. A more mature approach is to treat authorization as a lifecycle with distinct workflow stages that are planned, governed, and observable. In this episode, we’re going to focus on that lifecycle by walking through issuance, review, revocation, suspension, and governance as connected parts of one system. Issuance is how access is granted in the first place, ideally with clear justification and controlled approvals. Review is how you confirm that access still makes sense as roles and projects change. Revocation is how you remove access permanently when it is no longer needed or when risk demands it. Suspension is how you pause access temporarily without destroying the identity relationship, which can be important for investigations, leave periods, and risk containment. Governance is the framework that makes these steps consistent and auditable rather than ad hoc. For beginners, the key insight is that access is not a static switch; it is a living control that must stay aligned with reality, and workflows are how you keep that alignment without relying on memory and good intentions.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

A good way to ground this topic is to think about what goes wrong when authorization workflows are not designed. People get hired and receive broad access on day one because it is faster, then they change teams but keep old access because nobody remembers to remove it, then they leave but some accounts remain active because deprovisioning missed a system. In parallel, service accounts and automated processes collect permissions over time and are rarely reviewed because they are “not people,” even though they can be more powerful than people. These failures create orphan access, privilege creep, and confusing audit trails, all of which attackers can exploit. Even without attackers, these failures create operational risk because accidental changes can affect systems far beyond what was intended. Designing workflows means defining who can request access, who can approve it, how it is granted, how it is recorded, and how it is removed. It also means designing the exception path, because in real life there will be urgent needs and unusual scenarios. If the exception path is undefined, exceptions become informal and permanent, which is one of the fastest ways to destroy least privilege. An architect treats workflows as part of the control system, not as paperwork around the control system, because workflows are how intent becomes enforceable reality.

Issuance is the first stage, and it deserves more attention than simply handing out permissions. Issuance begins with a request, and the request must include a clear statement of what access is needed, why it is needed, and for how long it is needed. Without those elements, approvals become guesswork, and guesswork tends to result in overly broad access because approvers do not want to block work. A well-designed issuance workflow also defines whether access is granted by default based on role or whether it requires explicit approval for each permission set. Role-based issuance can be efficient when roles are well-defined, but it can be risky when roles are bloated or when job duties vary widely inside the same role label. Explicit approval can be safer for high-risk access, but it can also create friction that pushes people toward shortcuts if the process is slow. Architects balance these tensions by defining tiers of access: low-risk baseline access that can be automated, and higher-risk access that requires stronger justification and approval. Issuance also includes the technical act of granting access, but the design focus is that granting should be predictable and traceable, and it should not rely on manual edits that are hard to audit. For beginners, the important idea is that issuance is where privilege often becomes permanent, so time-bounding and clear justification should be baked in from the start.

Approvals are the center of issuance, and the biggest architectural challenge is defining who the right approver actually is. A manager may understand the person’s job responsibilities but may not understand the sensitivity of a particular data set. A system owner may understand the system’s risk but may not understand whether the user truly needs access to do their work. A data owner may understand the data’s sensitivity but may not be available for rapid approvals. These realities push architects to design approval paths that match the type of access. For example, access to a specific system might be approved by the system owner, while access to a sensitive data category might require a data owner’s approval, and privileged administrative access might require both plus additional oversight. Separation of duties also matters here because the requester should not be the approver, and high-risk approvals should not be concentrated in one person who can grant themselves powerful access. Another subtle point is that approvals must be meaningful, not rubber-stamped, which requires that approvers have enough information and enough context to make the decision. That is why issuance workflows often include standardized request fields and defined access packages rather than free-form requests. For beginners, the takeaway is that approvals are about accountability and risk understanding, not about slowing people down, and designing them well reduces both over-access and approval fatigue.

Once access is issued, review is the stage that keeps authorization aligned with changing reality, and this is where many systems quietly fail if reviews are treated as optional. Review means periodically confirming that access is still needed and still appropriate, and it can be performed at different levels. You can review individual entitlements, such as a particular permission set, or you can review role membership and group membership as proxies for many underlying permissions. Reviews are essential because people’s jobs change and projects end, yet access often remains unless something actively removes it. Reviews also address the problem of “unknown access,” where nobody can explain why a permission exists, which is a major governance red flag. A beginner misunderstanding is thinking reviews are purely compliance tasks, but reviews are also practical security controls that catch drift before it becomes an incident. The quality of review matters more than the frequency, because frequent reviews that no one understands become meaningless. Architects therefore design review workflows to be understandable, targeted at high-risk access, and supported by evidence such as last-used dates, associated tickets, and descriptions of what the access enables. When you design reviews well, you reduce privilege creep and create a culture where access is expected to be justified, not assumed.

A key part of review design is deciding what signals and context reviewers need so they can make a confident decision. If a reviewer sees a list of cryptic group names, they cannot meaningfully assess whether access is appropriate. If a reviewer sees a clear access package name, a description of what it allows, a justification from issuance, and evidence of recent use, the decision becomes easier and more accurate. Architects also consider who should perform the review, because the right reviewer depends on what is being reviewed. For ordinary business application access, a manager might be appropriate, while for sensitive data access, a data steward might be necessary. For administrative access, reviews often require security oversight because the risk is higher and the implications are broader. Another consideration is how to handle non-responses, because review workflows often fail when reviewers ignore them. A strong design defines what happens if review is not completed, such as escalating, temporarily suspending the access, or automatically revoking it for high-risk permissions. This is a delicate balance because you do not want to break essential operations, but you also do not want perpetual unreviewed access. For beginners, the point is that review is an active control that must have consequences, otherwise it becomes a ritual that attackers and auditors can both see through.

Revocation is the stage where access is removed permanently, and it has to be designed with the same care as issuance because removal can be incomplete or delayed. Revocation can occur for many reasons, such as a user leaving, a role changing, a project ending, a review failing, or a risk event requiring immediate containment. The technical act of revocation might involve removing group memberships, disabling accounts, deleting tokens, or changing policy rules, but the workflow design is about ensuring revocation propagates across all relevant systems. A beginner mistake is assuming revocation happens instantly everywhere, but in many environments some systems sync slowly or use cached entitlements, which creates windows where access still works. Architects therefore define acceptable revocation timelines for different access types and implement compensating controls where needed, such as revoking sessions or forcing re-authentication. Revocation must also handle the problem of indirect access, where a user’s access comes through nested groups or shared resources, making it easy to miss. Another important aspect is ensuring revocation is recorded with reason and timestamp, because revocation events are security-relevant and may be needed for investigations. For beginners, the key takeaway is that revocation is not just “take it away”; it is a controlled process of closing every door the access created.

Suspension is different from revocation, and understanding the difference helps you design workflows that support both security and operational reality. Suspension means temporarily disabling access without fully removing the underlying identity relationship or entitlements. This is useful in scenarios like an employee going on leave, a contractor pausing work, or an account being flagged for investigation. Suspension can also be used as a containment action during incident response, where you need to stop access quickly while you determine what happened. A beginner misunderstanding is thinking suspension is simply a softer version of revocation, but suspension has unique risks because suspended access must not silently reactivate without the right checks. If suspension is handled by a simple flag that can be toggled, you must govern who can toggle it and under what conditions. Suspension workflows should also define what happens to active sessions and tokens, because suspending an account without ending sessions can allow access to continue. Another consideration is that suspension may need to preserve data ownership and workflow continuity, such as allowing the organization to reassign tasks or manage resources while the account is suspended. Architects therefore design suspension as a clearly defined state with clear triggers, clear authority, and clear reactivation steps. For beginners, the main point is that suspension is a safety tool when permanence is not appropriate, but it must still be treated as a serious security state.

Reactivation, while not named in the title, is closely connected to suspension and deserves attention as part of workflow design because reactivating access is where mistakes can reintroduce risk. If an account was suspended due to suspicious activity, reactivation should require confirmation that the risk is resolved, not just a convenience toggle. If an account was suspended due to leave, reactivation should confirm that the person is returning and that their role and access are still correct. Reactivation is also a chance to review entitlements, because time away can coincide with organizational changes. Architects sometimes treat reactivation as a review-triggering event, requiring a manager to re-affirm access or requiring step-up verification. Reactivation also interacts with credentials: if you suspect compromise, you may require credential resets and token revocation before allowing access again. A beginner mistake is to think of reactivation as the opposite of suspension with no additional checks, but that can effectively turn suspension into a revolving door. The architectural point is that state transitions in authorization should be governed, because the state changes affect risk dramatically. Designing these transitions is part of keeping the system trustworthy.

Governance is the umbrella that holds issuance, review, revocation, and suspension together, and it is what prevents workflows from becoming inconsistent across teams and systems. Governance includes defining policies about who can approve what, which access requires periodic review, what the default review intervals are for different risk tiers, and what evidence must be captured. It also includes defining ownership of entitlements, so there is always someone responsible for maintaining and reviewing a permission set. Without entitlement ownership, access packages become orphaned, and orphaned packages tend to grow unchecked. Governance also includes change control for the access model itself, such as changes to roles, groups, and policies, because modifying a role can instantly change access for many users. Another governance element is metrics and reporting, because leadership and security teams need to know whether reviews are being completed, how many exceptions exist, and where the highest-risk access is concentrated. Monitoring also matters, because governance is strengthened when abnormal access assignments or failed revocations are detected quickly. For beginners, the key idea is that governance is not separate from access; it is the control system that makes access predictable, reviewable, and resilient over time.

Workflow design also must account for non-human identities, because services, automation, and integrations often have the most stable and least reviewed access in an environment. Issuance for service identities should require clear ownership, clear scope, and clear purpose, because service access can become a permanent backdoor if it is not governed. Reviews for service identities often need different signals, such as whether the service is still running, which systems call it, and whether its permissions match its current function. Revocation for service identities must consider dependencies, because removing access can break applications, but that risk should not justify leaving overly broad access in place indefinitely. Suspension can be useful for service identities during investigations, but it must be coordinated carefully to avoid unintended outages. Architects design service identity workflows with the same rigor as human workflows, often adding stricter controls because services can operate at high speed and can be exploited quietly. A beginner misunderstanding is to assume that because a service account is “owned by IT,” it is automatically safe. In reality, service identities are prime targets and must be treated as high-value assets with lifecycle workflows and governance. This is one of the clearest examples of how authorization is broader than user logins.

Designing authorization workflows is ultimately about keeping access aligned with purpose from the moment it is granted to the moment it is removed, while ensuring every stage is accountable and auditable. Issuance must require clear justification, appropriate approvals, and time-bounded design where possible so privileges do not become permanent by accident. Review must be meaningful, supported by understandable context and evidence, and tied to consequences so it actually reduces drift rather than producing paperwork. Revocation must be complete, timely, and propagated across systems and sessions so old access does not linger in hidden pathways. Suspension must provide a controlled temporary stop with strong rules for reactivation so it cannot be abused or misused. Governance must define ownership, change control, and monitoring so the workflow remains consistent as systems and organizations evolve. When these elements are designed as one coherent lifecycle, authorization becomes a living control rather than a collection of ad hoc decisions. If you can explain not only what each stage is but how they connect and why failure in one stage undermines the others, you are practicing the ISSAP mindset of designing security as a resilient system. The deeper lesson is that access is one of the most powerful tools in any environment, and workflows are how you keep that tool from becoming a quiet liability over time.