8.4 Access Control Matrices and Scenario Decisions
Key Takeaways
- An access control matrix maps subjects to objects and shows the permissions each subject has for each object.
- Rows often represent subjects or roles, columns represent objects, and cells list allowed actions.
- Decision tables help compare a request against policy conditions such as role, approval, location, time, and data sensitivity.
- Matrices are useful for clarity, but large environments usually implement them through groups, roles, policies, and tooling.
- Good scenario analysis identifies the subject, object, action, business justification, risk, and compensating controls.
Access Control Matrices and Scenario Decisions
Key Concepts
An access control matrix is a simple way to visualize authorization. One axis lists subjects, such as users, groups, roles, processes, or departments. The other axis lists objects, such as applications, files, databases, reports, or administrative functions. Each cell shows the permissions allowed for that subject and object. The matrix is not always the exact technology used by the system, but it helps people reason about access clearly.
For a small example, imagine a customer support system:
| Subject or role | Customer profile | Payment card data | Refund approval | Audit logs |
|---|---|---|---|---|
| Support analyst | Read, note | Masked view only | Request | No access |
| Support manager | Read, note | Masked view only | Approve up to limit | Read |
| Finance analyst | Read billing fields | Token reference only | Review | No access |
| Security auditor | Read | No access | Read | Read |
This table exposes design questions. Does the support analyst truly need to see full card numbers? Usually no. Should the support manager approve unlimited refunds? Probably no. Should the person who can approve refunds also be able to delete audit logs? No, because that would undermine accountability.
Large systems do not usually store one giant spreadsheet as the live control. Instead, they implement permissions through groups, roles, policies, access control lists, claims, tags, or identity provider rules. The matrix still matters because it provides a design and review view. During an access review, an application owner can look at the matrix and decide whether the current permissions still match business duties.
Decision tables are especially helpful for scenario questions because they show conditions and outcomes. For example:
| Condition | Allow refund approval? |
|---|---|
| User is support manager | Required |
| Refund amount is 500 dollars or less | Required |
| Customer case has documented reason | Required |
| Request comes from managed device | Required |
| User is approving own request | Deny |
Exam Application
This table combines role, transaction amount, documentation, device posture, and separation of duties. It also shows that one favorable condition is not enough. A manager using an unmanaged personal laptop should not approve the refund. A manager approving a refund they personally requested should be denied because the process lacks separation.
When answering exam scenarios, use a repeatable method. First, identify the subject. Is it an employee, contractor, process, service account, or outside partner? Second, identify the object. Is it a file, record, application function, API endpoint, or administrative console? Third, identify the action. Is the subject reading, changing, approving, deleting, exporting, or administering? Fourth, identify the business justification. Why does the subject need the action? Fifth, identify risk and constraints. Is the data sensitive, the action privileged, or the request temporary?
Sixth, choose the control that grants the needed access while reducing unnecessary exposure.
Consider a scenario where a vendor needs to troubleshoot a production application. A poor answer is to give the vendor a shared administrator password. A better answer is to create a named vendor account, require MFA, grant temporary access to the specific diagnostic tool, log the session, and remove the access when the work is complete. If production changes are needed, a company employee may approve the change through a separate workflow. That design applies least privilege, accountability, time limits, and separation of duties.
Access control matrices and decision tables are beginner-friendly because they turn vague access debates into visible choices. They help reveal excessive permissions, missing approvals, conflicting duties, and unlogged privileged actions. For the CC exam, they also train the habit of matching the control to the scenario rather than choosing the most technical-sounding answer.
What does an access control matrix primarily show?
A vendor needs temporary troubleshooting access to one production diagnostic tool. Which approach best supports least privilege and accountability?
In a decision table for refund approval, which condition best supports separation of duties?