Capability Table

What a capability table shows

A capability table is a structured way to show who can do what in a system. It makes permissions visible by mapping roles, users, or groups to functions such as approve, modify, administer, or review. That visibility turns access from an abstract policy into something that can be inspected, challenged, and governed.

Because the table is action-oriented, it usually sits closer to business and security operations than a pure role catalogue. It helps teams see whether access assignments match job function, whether privilege is broader than intended, and whether sensitive actions are concentrated in too few hands.

How capability tables support access review

Capability tables are useful because they let reviewers compare intended access with actual access in a single view. Instead of checking entitlements one by one, a reviewer can look across functions and identify where a role has unnecessary authority, where a user inherits too much from a group, or where a capability has no clear owner.

This is why the table is often used in access recertification, control testing, and approval workflows. It gives managers, application owners, and security teams a common reference for deciding whether a permission is justified and whether exceptions need to be removed or documented.

In practice, the table is only as good as the underlying role model. If roles are too broad, overlapping, or inconsistently named, the table can hide privilege creep rather than expose it. If functions are too granular, it can become hard to maintain and stop reflecting how the system is actually used.

Why capability tables matter for least privilege and segregation of duties

Capability tables matter because they make two control expectations easier to test: least privilege and segregation of duties. A well-built table shows whether a role has only the actions it needs, and whether any single user or role can both request and approve, create and delete, or otherwise combine incompatible powers.

That makes the table especially valuable where administrative actions, financial approvals, data changes, or privileged operations carry high business impact. It can also reveal “hidden” administrative capability, where a user appears normal on paper but still has powerful system-level functions through inheritance or indirect membership.

For organisations using formal control catalogues, the same mapping discipline can be aligned with stronger identity and access governance practice, including least-privilege enforcement and privileged access control as described in NIST SP 800-53 Rev 5 Security and Privacy Controls and the NIST Cybersecurity Framework 2.0.

Common design and maintenance pitfalls

Capability tables fail when they drift away from the real system. A table that is not updated after application changes, role redesigns, or delegated administration changes can give a false sense of control. The same is true when the table records nominal permissions but ignores effective permissions inherited through groups, service roles, or shared admin paths.

Another common weakness is treating the table as documentation only. If no one owns it, validates it, or uses it during approvals and recertification, it quickly becomes stale. In that state, it may still look authoritative while actually masking excess privilege, unused privilege, or conflicting duties.

Clear inventory and access discipline are important here. A capability table becomes more reliable when it is tied to current system design, role definitions, and periodically reviewed access data rather than copied from an old policy or spreadsheet.

How to use capability tables in governance workflows

In governance terms, a capability table works best as a decision aid, not as a substitute for judgment. It should support role design, access approval, periodic review, and exception handling, while remaining readable enough that non-technical owners can confirm whether a capability is appropriate.

For higher-risk systems, the table should distinguish between ordinary end-user actions and administrative or security-sensitive actions. That separation makes it easier to spot where elevated access is justified, where it should be time-bound, and where a narrower role could replace a broad one. It also helps teams compare what a user can do in the application with what policy says they should be able to do.

Where the table is used well, it becomes a practical governance artifact: a bridge between policy, entitlement review, and operational reality.

Risk and Threat Considerations

Capability tables can hide privilege creep, excess administrative access, and separation-of-duties conflicts if they are outdated or built from incomplete entitlement data. That creates a control gap that attackers, insiders, or simple process failure can exploit.

Failure mechanism: If effective permissions are not reconciled against the table, a user may retain powerful actions after a role change, inherit hidden access through groups, or combine incompatible capabilities without detection.

Impact: The result can be unauthorized changes, approval fraud, data manipulation, or broader privilege abuse, especially where the table is used as evidence of control but no longer reflects actual access.

Practitioner Guidance

Why practitioners should care: Use the capability table as a living control artifact, not a static inventory. The value comes from whether it still matches effective access and whether reviewers can understand it quickly enough to approve or challenge privilege with confidence.

Common misunderstanding: A complete-looking matrix is not the same as a trustworthy one. If group inheritance, delegated administration, or exception paths are omitted, the table may overstate how well access is governed.

Practitioner takeaway: The best capability tables are maintained from current entitlement sources and reviewed alongside access recertification, so they expose privilege drift instead of documenting it after the fact.

Related resources from NHI Mgmt Group

• What breaks when identity controls stop at table-level permissions?
• How should security teams prevent rainbow table attacks on password hashes?
• How should security teams govern PostgreSQL table discovery in production environments?
• Why do stored database credentials increase risk even for read-only table queries?