Certified: The ISC(2) CC Audio Course

In this episode, we’re going to explore a kind of access control that shows up in many everyday computing situations, especially in environments where flexibility and sharing are common. Discretionary Access Control (D A C) is a model where the owner of a resource, like a file or folder, has the ability to decide who else can access it and what they can do with it. That sounds reasonable because owners usually understand their work and want control over their own materials, but that same flexibility can create security problems when it is applied inconsistently or without clear boundaries. Many beginners assume access control is always centralized, like a school deciding who can enter a building, yet D A C often works more like roommates deciding who can borrow what in a shared apartment. The core purpose of learning this topic is to understand how ownership and permissions operate, why D A C is useful, and where it tends to fail in real organizations. By the end, you should be able to explain D A C in plain language, recognize what it looks like in practice, and describe why it can break down under pressure.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
A strong place to begin is with the idea of ownership, because D A C is built on the assumption that someone has legitimate authority over an object. Ownership means a system recognizes a specific user or entity as the one who created or controls a resource, and that owner can grant or remove access for others. In many operating systems and platforms, the owner is the person who created the file, the person who uploaded a document, or the account associated with the workspace. This is convenient because it supports the way people actually work, where individuals create documents and then share them with teammates. The problem is that ownership is not always the same as business responsibility, because the person who created something might not be the person who should control it long-term. When ownership is treated casually, sensitive information can be shared too broadly or left accessible after a project ends. The key beginner insight is that D A C treats access as a property decision made at the resource level, which is powerful, but also difficult to manage at scale.
Once you understand ownership, the next concept is permissions, because permissions are the specific actions the system allows someone to take. Permissions are not a single on or off switch, because access can mean many things, such as viewing, editing, deleting, or changing who else has access. In a D A C environment, the owner can typically grant permissions directly to another user or to a group, and they can often change those permissions later. This is useful because it enables collaboration without waiting on a central administrator for every decision. A beginner misconception is to think permissions only matter for security against attackers, but permissions also manage everyday risk, like preventing accidental deletion or preventing someone from editing a document they should only read. Another important misconception is to assume that if a person is authorized to read a file, they should automatically be authorized to share it, but D A C often allows sharing as a side effect of ownership that can grow access unexpectedly. Permissions are the language of D A C, and learning to think in permission levels helps you see how access quietly spreads.
In practical terms, D A C often shows up through Access Control List (A C L) structures, which are lists attached to a resource that specify who can do what. An A C L might define that a certain user can read a file, another user can write to it, and a group can have full control. The system checks the A C L when someone tries to access the resource, and if the A C L grants the requested action, access is allowed. For beginners, the important point is that D A C decisions are stored close to the resource, not only in a central policy document. That makes D A C flexible because changes can be made quickly by the owner, but it also makes D A C harder to oversee because different resources can have different A C L settings. Over time, those settings can become inconsistent, outdated, or overly permissive, especially when many people collaborate across many projects. This is one reason D A C is often described as convenient but messy, because the security outcome depends heavily on how many individual owners make careful decisions.
One reason organizations use D A C is that it matches how people naturally collaborate, especially in knowledge work. Teams often need to share documents rapidly, grant a coworker access for a short period, or create a new folder for a project and invite participants. D A C supports this without requiring a separate approval chain, and that speed can be critical in environments where work moves quickly. In cloud settings, D A C-like sharing can be even more common because collaboration platforms are designed around easy sharing and quick access grants. The security benefit is that the business can function without constant bottlenecks, and the technical burden on administrators is reduced. The security risk is that convenience can replace judgment, leading to broad sharing that nobody revisits. For beginners, the key idea is that D A C is popular because it is practical, but practical systems still need guardrails. If D A C becomes a default habit without oversight, it can create a slow leak of sensitive access across the organization.
Where D A C begins to break down is at scale, because a model based on individual discretion assumes that many individuals will make consistently good decisions. In reality, people are busy, they are interrupted, and they often do not understand the security impact of their choices. A person might grant access to an entire department because it is easier than selecting a few individuals, or they might choose a setting that allows anyone with a link to access a file because it saves time. They might also forget to remove access when a contractor’s work ends or when an employee changes roles. These are not dramatic mistakes, but they accumulate, and the accumulation becomes a significant risk. The organization ends up with access sprawl, where far more people can access far more resources than intended. When an incident occurs, access sprawl increases the blast radius because a compromised account might inherit access to many sensitive documents. D A C breaks down when discretion is not paired with review, guidance, and boundaries.
Another place D A C breaks down is when ownership is unclear or when resources outlive the original owner’s involvement. For example, a file might be created by an intern who leaves, but the file remains important to the business. If the intern’s account is disabled properly, the organization might lose the ability to manage the file easily, or it might rely on administrators to take over ownership. Alternatively, ownership might remain with an active employee who changed roles and no longer remembers what they shared and why. This creates a problem where critical resources exist, but their access rules are maintained by someone who is no longer connected to the business purpose. In a large organization, this can happen thousands of times, creating hidden risk that is hard to see. Beginners sometimes assume access control is always aligned with business structure, but D A C can drift away from business structure because it follows the history of who created things, not who should control them now. This is why organizations often create policies about resource ownership transitions and reviews. Without that, D A C becomes a historical accident that controls modern access.
A particularly important weakness in D A C is the ease of re-sharing, because the model often allows access to spread through social networks rather than through formal authorization. If I grant you access, you might grant someone else access, and then that person might share it again, especially if the platform makes sharing a one-click action. Over time, a resource that started as a small team document can become accessible to many people who were never intended to see it. In some environments, the owner may not even realize how widely the resource has been shared, especially if access is granted through groups that change membership. This is a classic example of how a convenience feature can become a security vulnerability. For beginners, the lesson is that D A C is not only about a single decision point. It is about a chain of discretionary decisions, and chains tend to drift. This is where the phrase where it breaks down becomes concrete, because D A C is strongest when sharing remains controlled and visible, and weakest when sharing becomes casual and invisible.
It helps to contrast D A C with Mandatory Access Control (M A C), because the differences clarify what D A C is really doing. In M A C, access decisions are driven by a central policy and labels, and individual users do not get to decide who else can access resources. M A C is stricter and often used where control must be consistent and where the cost of mis-sharing is extremely high. In D A C, the owner has discretion, which makes it more flexible but less consistent. Beginners sometimes assume stricter always means better, but stricter can be less usable and harder to adapt to everyday collaboration. The better way to think about it is that each model fits different risk needs and operational realities. D A C is often chosen because it supports rapid work and decentralized collaboration, while M A C is chosen when centralized control is required. Understanding this contrast helps you see why D A C exists and why it also needs extra management to avoid becoming a risk factory.
It is also useful to connect D A C to Role-Based Access Control (R B A C), because many modern environments combine these ideas rather than choosing only one. R B A C assigns permissions based on roles that reflect job duties, which can create a stable baseline of what people should be able to access. D A C then sits on top of that baseline, allowing owners to share specific resources as needed. The risk is that if D A C is too permissive, it can undermine R B A C by granting access far beyond what roles were designed to allow. The benefit is that D A C can fill gaps when roles cannot predict every collaboration need, such as a cross-team project or a temporary task force. For beginners, the takeaway is that access control in real organizations is often layered. R B A C provides structure, and D A C provides flexibility, and the art is keeping flexibility from defeating structure. When D A C is constrained by sensible defaults, expiration of access, and visibility into sharing, it can work alongside R B A C rather than against it.
Because the user reminder asks us to connect concepts to cloud security, it’s important to understand how D A C shows up in cloud environments and why it can become risky there. Cloud collaboration tools often make it extremely easy to share resources outside the organization, not just inside it, and a single misclick can expose sensitive data to the public internet. That risk is not theoretical; it is one of the most common ways organizations accidentally leak information. The same ease of sharing that makes cloud platforms valuable is what makes D A C-like controls dangerous when users do not understand the implications. Cloud environments also tend to have many integrations, meaning resources can be shared with apps, services, and automated accounts, which adds complexity to the access picture. Beginners can think of cloud sharing as D A C with a megaphone, because it can spread access far and fast. That is why cloud security often adds guardrails like policy enforcement, monitoring, and default settings that reduce the chance of accidental broad sharing.
Monitoring and review are the practical tools that help D A C remain safe, because without them, discretion becomes invisible and unaccountable. Monitoring can include tracking sharing events, watching for resources that become publicly accessible, and alerting when sensitive categories of data are shared broadly. Review includes periodic checks where owners confirm who still needs access and remove those who do not. Beginners sometimes think review is busywork, but review is what corrects natural drift in permissions over time. A review process also helps educate owners, because it forces them to think about what they shared and why, and it creates a moment to correct overly broad grants. In cloud security, monitoring and review are especially important because sharing settings can change quickly and because exposure can have immediate consequences. Good D A C practice is not merely allowing owners to decide. It is supporting owners with visibility and accountability so their decisions remain aligned with the organization’s risk tolerance.
Another practical way organizations keep D A C from breaking down is by using sensible defaults and limited sharing options, because defaults shape behavior more than policy memos do. If the default is private and requires deliberate steps to share, owners are less likely to expose resources accidentally. If the default is broad, people will accept it because it seems normal, and risk will grow quietly. Organizations can also restrict certain kinds of sharing, such as preventing public access for specific data types or requiring additional confirmation steps when sharing outside the organization. These are not meant to remove discretion entirely, but to channel discretion into safer patterns. For beginners, the idea is that systems should guide people toward safe choices instead of expecting perfect judgment all the time. This aligns with the broader security principle of designing for human behavior, not against it. D A C works best when the environment makes the secure choice easy and the risky choice deliberate.
It is also worth addressing the human psychology that makes D A C both attractive and dangerous, because understanding that psychology helps you predict where problems will arise. People want to be helpful, they want to unblock work, and they often fear being the person who slows a project down. When someone asks for access, the easiest social response is to say yes quickly. In a D A C environment, that social pressure can become an access grant with long-lasting consequences. Beginners sometimes imagine security failures as technical glitches, but many are social defaults that become technical outcomes. The better approach is to normalize safe access behavior, such as granting the minimum needed access, setting expectations that access requests will be reviewed, and encouraging people to remove access when work ends. When these habits are part of culture, D A C becomes less risky because discretion is exercised thoughtfully. When culture rewards speed above all else, D A C breaks down because discretion becomes automatic approval.
As we bring everything together, it helps to see D A C as a model that can be perfectly reasonable in the right context, but it must be understood honestly. D A C gives owners power to share resources, which supports collaboration and keeps work moving, and that is why it is so widely used. The weaknesses come from scale, drift, unclear ownership transitions, and the ease of re-sharing, all of which can turn flexible access into uncontrolled access. In cloud environments, those weaknesses can be amplified because sharing can extend outside the organization quickly, and because integrations add complexity. The practical solution is not to pretend D A C is bad and must be eliminated everywhere. The practical solution is to add guardrails, visibility, review, and sensible defaults so discretion remains aligned with business need and risk tolerance. When D A C is combined thoughtfully with structured approaches like R B A C and stricter controls like M A C for the most sensitive areas, the organization can get both flexibility and safety.
In conclusion, Discretionary Access Control (D A C) is an access model built around ownership, where the owner of a resource can grant and revoke permissions, often through structures like an Access Control List (A C L). It matters because it enables fast collaboration and practical sharing, which is especially common in cloud-driven work where teams need to move quickly. The same convenience that makes D A C useful is what makes it vulnerable to access sprawl, re-sharing chains, and outdated permissions that remain long after their purpose is gone. D A C often breaks down when ownership is unclear, when people are pressured to grant access quickly, or when organizations fail to monitor and review sharing over time. By contrasting D A C with Mandatory Access Control (M A C) and connecting it to Role-Based Access Control (R B A C), you can see how organizations blend models to balance flexibility and consistency. The key takeaway for new learners is that D A C is not automatically insecure, but it is naturally prone to drift, so real security comes from pairing discretion with guardrails, visibility, and disciplined cleanup that keeps permissions aligned with what people truly need.