Subjects, Objects, and Permissions

Key Concepts

Logical access control is the part of security that answers a practical question: "Who or what is allowed to do this?" In that question, the "who or what" is the subject, "this" is the permission or action, and the protected thing is the object. On the ISC2 CC exam, this belongs to Domain 3, Access Controls Concepts, which is weighted 22 percent in the current outline effective Oct 1 2025. The new outline is effective Sep 1 2026. The current CC exam is computer adaptive testing, or CAT, with 100-125 items, a 2 hour time limit, and a 700 out of 1000 passing grade.

In everyday operations, a subject is not always a human employee. A subject can be a help desk analyst signing in to a ticketing system, a database backup job, a payroll application, a service account used by an integration, or an AI bot that submits requests through an API. The key point is that the subject is the active entity making a request.

An object is the passive resource being protected. Objects include files, folders, database rows, customer records, source code repositories, cloud buckets, network shares, printers, containers, APIs, and management consoles. Some objects are sensitive because of confidentiality, such as employee Social Security numbers. Others are sensitive because of integrity, such as firewall rules or payroll rates. Others affect availability, such as a production server restart command.

Permissions describe the action the subject may take on the object. Common permissions include read, write, create, delete, execute, modify, approve, print, export, administer, and share. Good access control design avoids broad phrases unless they map to real controlled actions. "Can update contact information" is clearer than "has customer access." "Can approve refunds up to 500 dollars" is more useful than "has finance access."

Think through a scenario. A support analyst receives a call from a customer who cannot sign in. The analyst may need permission to view the customer's account status and trigger a password reset workflow. The analyst should not need permission to view full payment card data, change the customer's email address without verification, export all customers, or disable audit logs. The subject is the analyst, the object may be the customer account record, and the permitted actions are limited to the support workflow.

Access control is not just a one-time login decision. Authentication proves or verifies the subject's identity, but authorization decides what the authenticated subject may do. Accountability depends on logging the subject, action, object, time, source, and result. If many people share one account, the organization may know that "admin" changed a rule but not which person actually did it. That weakens accountability even if the access decision technically worked.

Exam Application

A useful beginner method is to write access decisions as simple triples:

This format forces clarity. If you cannot identify the subject, object, and permission, you probably do not understand the access requirement yet. That is a warning sign in both exam questions and real work. When a scenario says "give the contractor access," slow down and ask: access to what object, for what action, for how long, from where, and under whose approval?

Logical access controls support business work, but they also limit damage. If an account is compromised, the attacker's options are limited by the permissions assigned to that subject. If a user makes a mistake, narrow permissions reduce the chance that one mistake becomes a major incident. Strong access control is therefore not just a compliance task. It is a daily risk reduction practice that connects identity, policy, monitoring, and operational discipline.