Certified: The ISC(2) CGRC Audio Course

In this episode, we take the baseline controls you identified and the inherited controls you documented, and we answer a question that looks simple but is a major source of compliance chaos: which controls actually apply to this system, and how do we account for them without double-counting. Double-counting is what happens when the same control requirement is claimed twice, or when multiple parties each assume the other is fulfilling it, and both situations can produce the worst outcome: a control that looks covered on paper but is not actually covered in practice. Applicability is about deciding whether a control requirement is relevant to your system’s scope and context, and if it is relevant, how it is satisfied, whether by the system itself, by a shared service, or by a combination. The goal here is to build a clean, traceable mapping that says this control applies, this is how it is met, and this is who owns each part. By the end, you should be able to walk into a review meeting and explain control applicability calmly, without hand-waving, and without accidentally counting one safeguard as two different controls.

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.

Start by grounding the meaning of applicability in framework thinking. A baseline is a default set of control requirements, but frameworks usually allow some controls to be marked not applicable when they truly do not fit the system’s characteristics. Not applicable does not mean inconvenient, expensive, or unpopular, and it does not mean we already have something similar. It means the requirement is genuinely irrelevant because the system does not perform the function the control addresses or the condition the control assumes does not exist in scope. For example, a control about wireless networking might be not applicable if the system has no wireless components in its boundary, and a control about physical media might be not applicable if the system never uses physical removable media in scope. The framework typically expects that not applicable decisions are justified with clear reasoning, not vague statements. This is why earlier boundary definition work matters, because applicability depends on what is in scope, what environments are used, and what information types flow through the system. When you treat applicability as a disciplined decision, it becomes defensible rather than suspicious.

Now bring inherited controls into the picture, because inheritance is not the same thing as not applicable. A control can apply and still be inherited, meaning the requirement matters, but the system satisfies it through a shared service. If you mark an inherited control as not applicable, you are saying the requirement itself does not matter, which is rarely what you mean. The cleaner approach is to mark the control as applicable and then document its implementation status as inherited, including the control provider and the system’s integration responsibilities. This keeps the control in the control set, which is what frameworks and assessors expect, while avoiding redundant implementation. It also avoids a subtle but dangerous mistake where teams treat not applicable as a way to hide complexity. When you call something inherited, you are acknowledging the requirement and showing how it is met; when you call something not applicable, you are saying the requirement does not apply at all. That distinction is one of the biggest clarity wins you can develop.

To prevent double-counting, you need to separate the idea of a control requirement from the mechanisms that satisfy it. One control requirement might be satisfied by multiple mechanisms, but it is still one requirement, and you should not claim each mechanism as if it were a separate control. For example, an access control requirement might be supported by centralized authentication, role definitions in the application, and periodic access reviews. Those are multiple pieces, but they collectively satisfy one requirement, and you document them as parts of one control implementation. Double-counting happens when someone lists centralized authentication as satisfying the access control requirement and then also lists application role checks as satisfying a different access control requirement, without mapping to the actual control statements. A clean mapping keeps each control requirement as the unit of accounting, and then maps mechanisms and ownership to that unit. This is why frameworks emphasize traceability, because traceability forces you to show exactly which requirement is being met.

A practical way to determine applicability is to walk through each control family and ask what assumption the control is making about the system, then check whether that assumption is true in your defined scope. If a control assumes that the system has users, then it likely applies, because most systems do. If a control assumes that the system stores sensitive information, you check your information types and objectives to confirm whether that condition exists. If a control assumes that the system has software changes, then configuration management and change control likely apply. If a control assumes that the system produces audit records, then logging requirements likely apply, and most systems do produce some form of event data. If a control assumes external connections, then boundary protection and secure communications controls apply. This assumption-checking approach keeps you from treating controls as abstract paperwork and instead treats them as responses to real system conditions. It also helps you write better justifications because you can state the condition and your evidence about whether it exists.

When inherited controls are involved, you also need to confirm that the system is actually within the inherited control’s coverage, because inheritance can be partial or conditional. For example, a shared logging service might be available, but a system might not be fully onboarded, or it might only send infrastructure logs and not application logs. A shared identity service might cover employees but not external partners, meaning some user populations are covered and others require system-specific identity handling. A common network boundary might protect production but not a development environment used for testing, which can still be in scope depending on your assessment. Applicability is not just about whether the control requirement is relevant, but whether the inherited implementation truly satisfies the requirement for the in-scope components. If the inherited service does not cover your system fully, then the control still applies, but you must document the gap as system responsibility or as a required onboarding step. This is where double-counting often hides, because people assume coverage and then both sides move on.

Another area where double-counting appears is when a control requirement includes multiple parts, and teams split it in ways that are not documented. For example, a requirement might involve both policy and technical enforcement, and one team claims the policy while another claims the enforcement, but no one claims the overall control. If you document each part separately without connecting them, the control can appear implemented even if the policy and enforcement do not align. A disciplined approach is to treat the control as a whole and list which party is responsible for which part, including who owns the policy, who operates the technical mechanism, and who provides evidence during assessment. Then you state how the parts work together, such as the policy defining rules that are enforced by centralized identity and verified through logs and periodic review. This is not making the work bigger; it is making the work visible so it can be verified. Visibility is what prevents a compliance story from falling apart under questioning.

It also helps to distinguish control applicability from control effectiveness, because they are related but not the same decision. A control can apply even if it is not currently implemented well, and in that case the correct response is not to mark it not applicable but to treat it as a gap to address. Beginners sometimes want to avoid uncomfortable findings by claiming not applicable or inherited without evidence, but that creates bigger problems later. Applicability is about relevance to the system’s characteristics and scope, while effectiveness is about whether the implementation meets the control intent. When you keep these separate, you can have honest conversations that say yes this control applies and we meet it through shared service X, or yes it applies and we partially meet it but need additional actions. That honesty is what makes your control set defensible. It is also what lets the organization prioritize remediation rationally, rather than fighting over labels.

To determine applicability cleanly, you want a consistent set of status categories that reflect reality. At a minimum, you need to distinguish system-implemented, inherited, partially inherited, and not applicable, and you also need a way to note planned or in-progress work if your process allows it. The important part is that each control has exactly one primary status, and if it is partially inherited, you explicitly describe the split responsibilities. Avoid having the same control appear twice in different places, like listing it under a shared service section and again under system controls without cross-reference, because that is how double-counting sneaks in. Instead, keep one authoritative control record per control requirement and let that record reference shared services as needed. This makes it easy to answer questions like which controls are inherited and which are owned by the system team, and it prevents contradictory claims. Consistency here is a form of risk reduction because it prevents misunderstandings.

A very common trap is the assumption that if two controls sound similar, one can cover the other, which can lead to accidental double-counting or accidental omission. Control frameworks often have multiple controls that touch the same general area, like access, logging, or incident response, but each has a different emphasis. One might focus on account provisioning, another on access enforcement, another on review, and another on privileged functions. If you claim that centralized identity covers all access-related controls, you may be overstating inheritance because some requirements are about application-level authorization, some are about administrative processes, and some are about monitoring. The safe approach is to map each control requirement individually to the mechanism and owner that satisfies it, even if many map to the same shared service. This is not busywork; it is precision. Precision is what keeps you from saying we have S S O so access is solved, and then discovering during assessment that role review or privileged access monitoring was never addressed.

By the end of this lesson, you should have a clear, calm approach to control applicability that keeps baseline expectations, inherited implementations, and system responsibilities distinct. You determine whether each control requirement is relevant based on system scope and characteristics, not convenience, and you document how each applicable control is satisfied without splitting it into disconnected parts or counting it twice. You treat inheritance as a method of implementation, not a reason to remove controls from the set, and you verify that inherited coverage actually includes your system components and populations. You keep applicability separate from effectiveness so you can be honest about gaps without mislabeling them. When you do all of this, you produce a control selection that can survive scrutiny because it tells a coherent story: here is what applies, here is how it is met, and here is who owns each piece, with no double-counting and no hidden holes.