DAC, MAC, RBAC, and ABAC are access-control models that answer the same basic question in different ways: who or what is allowed to perform an operation on a resource? The important differences are who controls the policy, what information the decision uses, and how consistently the policy can be enforced across a system.

The current ISC2 SSCP outline has a dedicated Access Controls domain, while ISC2 CISSP also treats authorization as part of Identity and Access Management. For exam scenarios, do not choose a model by acronym recognition alone. Identify where authority lives and what facts drive the decision.

Discretionary access control puts significant authority with the resource owner

Discretionary Access Control (DAC) allows an owner or another authorized principal to decide who can access an object. File-system permissions are a common illustration: the owner of a file can grant read or write access to selected users or groups, subject to the platform’s rules.

The strength of DAC is flexibility. Owners close to the data can share resources without waiting for a central policy administrator. The weakness is that control can become inconsistent or overly permissive when thousands of owners make different decisions. Access can also spread when authorized users copy data into locations governed by different permissions.

In an exam question, look for owner-controlled permissions, access-control lists associated with individual objects, and the ability for an authorized user to delegate access. Those clues generally point toward DAC.

Do not confuse discretionary access control with products named “Dynamic Access Control”

The initials DAC can be reused in product terminology. A feature called Dynamic Access Control may apply centralized claims or classification logic and is not the same concept as the classic Discretionary Access Control model. Always expand the acronym from the scenario before deciding which model is being tested.

Mandatory access control uses centrally enforced labels and policy

Mandatory Access Control (MAC) is associated with centrally administered policy in which subjects and objects receive security labels or classifications. Users cannot simply change the policy because they own a file. The system enforces access according to the relationship between a subject’s authorization and an object’s classification or category.

Military and government classification systems are the common teaching example: information can be labeled Confidential, Secret, or Top Secret, with additional compartments or categories. The exact implementation varies, but the defining characteristic is that policy is mandatory and centrally controlled rather than discretionary to the individual owner.

MAC can provide strong consistency for environments where information-flow rules must override user preference. The tradeoff is administrative complexity and reduced flexibility. Label design, clearance management, classification changes, and handling rules all become part of operations.

Role-based access control assigns permissions to job functions

Role-Based Access Control (RBAC) assigns permissions to roles and then assigns users or service identities to those roles. Instead of granting every employee individual permissions, the organization defines roles such as Accounts Payable Clerk, Database Operator, or Security Analyst and associates permissions with the job function.

RBAC works well when access requirements are relatively stable and align with organizational responsibilities. It supports least privilege and separation of duties when roles are designed carefully. Joiner, mover, and leaver processes can add or remove role memberships as people change jobs.

The main failure mode is role explosion. If every small exception creates a new role, an organization can end up with hundreds or thousands of overlapping roles that are difficult to govern. Periodic access reviews then become a cleanup exercise rather than a meaningful control.

Roles should represent durable responsibility, not every temporary condition

If access depends on time of day, device posture, transaction value, customer region, data sensitivity, project assignment, and risk score, forcing every combination into a distinct role becomes unmanageable. That is where attribute-aware policy can complement RBAC.

Attribute-based access control evaluates facts at decision time

Attribute-Based Access Control (ABAC) evaluates attributes associated with the subject, resource, requested action, and sometimes the environment against policy. A rule might permit a clinician to view a patient record only when the clinician is assigned to that patient, is using a managed device, is located in an approved jurisdiction, and is requesting a permitted operation.

Attributes can include department, clearance, employment type, resource classification, data owner, device trust, network zone, time, location, risk level, transaction context, and many other facts. This expressiveness allows fine-grained policy without creating a role for every possible combination.

ABAC’s challenge is governance. Attribute sources must be authoritative, values must be accurate and current, policies must be understandable, and conflicts must be resolved predictably. A powerful policy engine built on stale identity data can make very precise wrong decisions.

Compare the decision source for each model

DAC asks whether an owner or authorized principal has granted the requested access. MAC asks whether centrally assigned labels and mandatory policy permit the information flow. RBAC asks whether the subject holds a role whose permissions include the requested operation. ABAC asks whether a policy evaluates the relevant subject, object, action, and environmental attributes to an allow or deny result.

These are conceptual models, not mutually exclusive product categories. A platform can use role membership as one attribute in an ABAC policy. A mandatory-label system may also use roles for administrative functions. A file system can apply discretionary permissions while a separate data-loss policy restricts what users can do with sensitive content.

For exam questions, first identify the dominant authorization logic described in the scenario. Then consider whether another model is being layered on top for a different purpose.

Choose the model by governance and scale

DAC can be appropriate when resource owners genuinely understand sharing decisions and the risk of decentralized control is acceptable. MAC fits environments that require non-discretionary information-flow policy and strong classification enforcement. RBAC is effective when job functions are stable and permissions map cleanly to organizational responsibilities. ABAC becomes valuable when authorization depends on dynamic context or many attributes that cannot be represented cleanly as roles.

Scalability is not only a user-count problem. It is a policy-complexity problem. Ten thousand users with twenty well-designed roles may be easier to govern than five hundred users with hundreds of exceptions. Conversely, one broad role may be dangerously permissive if the actual business rule depends on data sensitivity and transaction context.

Administrative authority also matters. A system with regulated information may require central policy and auditable approvals even if a user technically “owns” the data. The best model is the one that expresses the required control with the fewest ambiguous exceptions.

Watch separation of duties and least privilege across every model

No model automatically guarantees least privilege. An RBAC role can contain excessive permissions. An ABAC policy can be written too broadly. A DAC owner can overshare. A MAC label can be misclassified. Governance must therefore include role or policy design, approval, testing, review, revocation, logging, and exception handling.

Separation of duties may require mutually exclusive roles, approval workflows, transaction constraints, or policies that prevent one person from controlling an entire sensitive process. Privileged administration should be separated from normal user activity and reviewed independently.

Temporary and emergency access need explicit handling. A “break glass” path should be time-limited, strongly authenticated, logged, and reviewed rather than implemented as permanent membership in an overpowered role.

Centralized policy does not eliminate the need for clear ownership. Every access rule still needs a business owner who can explain why the permission exists, which risk it addresses, and when it should be removed. Role catalogs, attribute dictionaries, classification schemes, and exception registers should therefore have lifecycle governance just like accounts do.

Auditability is another selection factor. An authorization engine should be able to explain which role, label, owner grant, or attribute rule produced a decision. If administrators cannot reconstruct why a user was allowed to read a sensitive record, troubleshooting and access reviews become guesswork. ABAC policies in particular should be written so that human reviewers can understand the conditions and test representative combinations rather than relying on opaque expressions.

Performance and availability matter too. A highly dynamic ABAC policy may depend on several real-time attribute sources. If one source is unavailable, the organization needs a defined fail-open or fail-closed behavior appropriate to the risk. RBAC can be simpler to cache and reason about, while MAC systems may depend on consistent labeling. The authorization model is therefore both a policy choice and an operational architecture choice.

A small number of explicit policy principles can prevent exception sprawl: deny by default, grant only the permissions needed for a defined business purpose, expire temporary access automatically, and require a new approval when the purpose changes. Those controls apply regardless of whether the implementation is role-, label-, owner-, or attribute-driven.

Use hybrid access control deliberately

Modern enterprise authorization often combines models. A user may receive baseline permissions through RBAC, while ABAC adds conditions based on resource classification, device status, location, and risk. Resource owners may retain limited discretionary sharing within centrally defined boundaries. Mandatory labels may constrain certain high-sensitivity data regardless of role.

The architecture goal is not theoretical purity. It is to make authorization decisions consistent, explainable, testable, and revocable. Policy administrators need to know which system is authoritative when two mechanisms disagree and how a denied or allowed decision can be traced.

Across ISC2 certifications, a reliable way to answer access-control questions is to identify the policy authority and the inputs to the authorization decision. Owner choice suggests DAC, central labels suggest MAC, job function suggests RBAC, and contextual attributes evaluated by policy suggest ABAC.