8.1 Subjects, Objects, and Permissions

Key Concepts

Logical access control answers a single operational question: "Who or what is allowed to do this, to what, and how?" The subject is the "who or what," the object is the protected "what," and the permission is the specific action that joins them. On the ISC2 CC exam this material sits inside Domain 3, Access Controls Concepts, weighted 22 percent under the current outline effective Oct 1 2025. A refreshed outline takes effect Sep 1 2026, so candidates testing after that date should pull the official PDF from ISC2 rather than trusting any third-party domain weights.

The CC exam itself is computer adaptive testing (CAT): 100-125 items delivered in a 2-hour window, scored on a scaled system where 700 of 1000 passes. The exam fee is $199, with a $50 Annual Maintenance Fee owed yearly after you certify. Because the exam adapts, two candidates rarely see the same items, and the test may end at 100 questions if the algorithm is already confident in your score.

A subject is rarely just an employee. It can be a help-desk analyst signing in to a ticketing tool, a nightly database backup job, a payroll application, a service account wiring two systems together, or an AI bot posting requests through an API. The defining trait is that the subject is the active entity initiating a request.

An object is the passive resource being protected: files, folders, database rows, source-code repositories, cloud storage buckets, network shares, printers, containers, API endpoints, and management consoles. Objects matter for different reasons. Some carry confidentiality weight (an employee Social Security number). Some carry integrity weight (a firewall rule or payroll pay rate). Some affect availability (a production-server restart command).

A permission describes the action allowed: read, write, create, delete, execute, modify, approve, print, export, administer, or share. Strong design names the exact action. "Can approve refunds up to $500" beats "has finance access"; "can update contact fields" beats "has customer access." Vague labels hide privilege creep.

Access control also maps to the IAAA model the exam loves: Identification (claiming an identity), Authentication (proving it), Authorization (deciding allowed actions), and Accounting (logging what happened). Authentication is not authorization. Verifying that Maria is Maria does not decide whether Maria may export the customer table.

Exam Application

A beginner-proof method is to write every access decision as a triple. If you cannot name the subject, object, and permission, you do not yet understand the requirement, and that gap is a red flag in both exam items and real reviews.

Work a scenario. A support analyst takes a call from a customer who cannot sign in. The analyst needs to view account status and trigger a password-reset workflow. The analyst should not see full payment-card numbers, silently change the customer's email, export all customers, or disable audit logs. Subject = analyst; object = the customer account record; permitted actions = the narrow support workflow only.

Watch the accountability trap. If five admins share one "admin" login, logs show that "admin" changed a firewall rule but cannot prove which human did it. The access decision technically worked, yet attribution failed. Common CC distractors phrase this as "the system logged the change, so accountability is met" — that is false when the account is shared.

Finally, remember access control is continuous, not a one-time login gate. A compromised account is limited to the permissions its subject holds, and a user mistake is contained by narrow permissions. When a scenario says "give the contractor access," slow down and ask: access to which object, for which action, for how long, from where, and approved by whom? That habit converts a vague request into a defensible, least-privilege decision.

Logging the Six Facts of Accountability

The accounting leg of IAAA only works if logs capture enough to reconstruct events. CC scenarios reward answers that record the full picture rather than a fragment. A defensible access log entry should hold six facts:

• Subject — the specific authenticated identity, never a shared label.
• Action — the exact permission exercised (read, modify, approve, delete, export).
• Object — the resource acted upon, ideally by unique identifier.
• Time — a synchronized timestamp; clock drift undermines forensic correlation.
• Source — the originating device, IP address, or network location.
• Result — success or failure, including denied attempts.

Denied attempts matter as much as successes. Repeated authorization failures against a sensitive object can signal a compromised credential probing for reach, and that signal is lost if only successes are logged.

Tie this back to the triad the whole certification orbits. Access decisions protect confidentiality by withholding read access to data a subject has no business viewing, protect integrity by limiting who may modify or approve, and protect availability by restricting destructive actions such as deleting records or restarting production hosts. A single over-broad permission can threaten all three at once, which is why the exam keeps returning to the discipline of naming subject, object, and action precisely before granting anything.