DAC, MAC, RBAC, and ABAC

Key Concepts

Access control models are patterns for making authorization decisions. The ISC2 CC exam expects you to recognize the model that best fits a scenario, not to memorize obscure theory. Start by asking: who controls the permission, what information drives the decision, and how flexible is the rule?

Discretionary access control, or DAC, gives the owner or authorized controller of an object discretion to share it. A simple example is a document owner granting another user read or edit access to a file. DAC is common in operating systems, shared drives, collaboration tools, and many cloud productivity platforms. It is flexible and user friendly, but that flexibility creates risk. A user may accidentally share a sensitive file with too many people or grant edit rights when read rights would be enough.

Mandatory access control, or MAC, is more centralized and rigid. Access is based on labels, classifications, and clearances that ordinary users cannot change. For example, a document labeled Secret may be readable only by subjects with Secret clearance and a valid need to know. MAC is often associated with military, government, and highly regulated environments where information classification must be enforced consistently. The object owner cannot simply decide to share a Top Secret file with a user who lacks the proper clearance.

Role-based access control, or RBAC, assigns permissions to roles that represent job functions. Users are then assigned to roles. A hospital may have roles such as emergency nurse, attending physician, billing clerk, pharmacist, and system administrator. Each role receives a defined set of permissions. RBAC is widely used because it scales better than assigning permissions to each user one by one. When a new billing clerk is hired, the identity team can assign the billing clerk role instead of manually selecting dozens of permissions.

RBAC must be managed carefully. If roles are too broad, users receive excess permissions. If roles are too narrow, organizations create role sprawl, where hundreds of tiny roles become hard to understand. Good RBAC maps roles to real job duties, separates conflicting responsibilities, and includes periodic review.

Attribute-based access control, or ABAC, uses attributes to make decisions. Attributes may describe the subject, object, action, environment, or risk signal. Examples include department, employment status, project code, data classification, device compliance, network location, time of day, and transaction amount. An ABAC rule might allow a claims adjuster to approve claims only for assigned regions, from a managed device, during business hours, and only below a dollar threshold. ABAC can be powerful because it handles context, but it depends on accurate attributes and well-tested policies.

Many real systems combine models. A file sharing app may use DAC when a user shares a document, RBAC for administrator privileges, and ABAC to block downloads from unmanaged devices. A cloud environment may use roles for job functions and attributes for resource tags. For exam purposes, choose the model that drives the main access decision in the scenario.

Exam Application

Use this quick decision table:

Suppose a project manager creates a folder and invites two contractors. That is DAC. Suppose a classified report is labeled Confidential and only cleared personnel can read it. That is MAC. Suppose all help desk analysts can reset passwords but cannot approve payments. That is RBAC. Suppose access is allowed only when the analyst is on the corporate network using a compliant laptop. That context-aware layer is ABAC.

The strongest answer depends on the business need. DAC is flexible, MAC is strict, RBAC is manageable for job functions, and ABAC is adaptive to context.