Implementing Asset Management & Access Control

Foundation's Annex A lessons covered what asset management (5.9-5.14) and access control (5.15-5.18) require. This lesson is about actually building them — an inventory people keep updated, a classification scheme people can actually apply, and an access lifecycle that survives someone's first day and last day alike.

Asset inventory: keep the tiers workable

A classification scheme with too many levels becomes unusable — nobody consistently applies a 7-tier system correctly. Most organizations land on 3-4 workable tiers:

The inventory itself doesn't need to be exotic tooling — a small organization can maintain a well-governed spreadsheet or a lightweight CMDB; what matters is that it's actually kept current (tied to an owner and review cycle, same discipline as the policy framework) and that every asset has a classification, not just the ones someone remembered to tag.

The joiner-mover-leaver lifecycle

Access control implementation is best designed around three life-cycle events, not as one-off rules:

JOINER  → Provision access matching the role, no more.
           Approval required before first access, not after.
MOVER   → Access changes with role changes — old access
           REMOVED, not just new access added. (The most
           commonly skipped step — "access creep.")
LEAVER  → Access revoked, ideally same-day, ideally
           triggered automatically by an HR system event
           rather than a manual step someone might forget.
           (Foundation's 6.5 finding, revisited here as an
           implementation problem, not just a concept.)

Access creep — accumulating permissions across role changes without ever losing old ones — is one of the most common real-world access control failures. Someone who moves from Support to Engineering to Team Lead over three years often ends up with all three roles' permissions stacked, because the "mover" step only ever added access and never reviewed what should be removed.

Why role-based access control (RBAC) scales

Assigning permissions per individual doesn't scale past a handful of people — every new hire requires someone to manually decide their exact permission set from scratch, and every audit requires manually verifying each person's permissions individually. Role-based access control assigns permissions to defined roles (e.g., "Support Agent," "Backend Engineer," "Finance Analyst") and assigns people to roles instead. This makes least privilege — giving only the access actually needed for the job — something you design once per role, rather than negotiate per person, and makes an access review a matter of checking "does this person's assigned role match their actual job?" rather than auditing dozens of individually-granted permissions from scratch.

Setting a real access review cadence

Foundation's SoA lesson emphasized that a control claim needs evidence — "we review access" is not evidence; a dated, completed review with a named reviewer is. A common, defensible cadence is quarterly for privileged/administrative access and semi-annual or annual for standard access, though the right cadence should be justified by the risk register (higher-risk systems reviewed more often), not picked arbitrarily. Whatever cadence is chosen, the review needs a clear, repeatable process: a list of current access is generated, a reviewer (ideally the resource/control owner, not IT alone) confirms each entry is still appropriate, and any flagged access is revoked with the action documented — closing the loop back to the risk register and, where relevant, the internal audit program covered later in this roadmap.