Episode 25 — Identify Baseline Controls and Explain Why They Exist in the Framework
In this episode, we take the impact level decision you made and turn it into something concrete: baseline controls. Baseline controls are the starting set of safeguards your selected framework expects a system to have, given its categorization and context, and they exist so organizations do not reinvent security from scratch every time they build a system. For beginners, the hardest part is often not listing controls, but understanding why a framework insists on certain controls even when they feel inconvenient or unrelated. The answer is that frameworks are built from hard-earned lessons about how systems fail in predictable ways, and baselines are a way of packaging those lessons into repeatable requirements. If you treat baseline controls as random boxes to check, you will struggle to explain them and you will struggle to tailor them later without breaking intent. The goal here is to learn how to identify the right baseline for your system and describe, in plain language, what problem each control family is trying to prevent or detect. By the end, you should be able to look at a baseline and say not only what it includes, but why those expectations show up in the first place.
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 with the idea that a baseline is not a perfect security design, and it is not a promise that nothing bad will ever happen. A baseline is a minimum set of controls that, if implemented reasonably, reduces common risks to an acceptable level for a given impact category. Frameworks create baselines because they need consistency across many systems, teams, and organizations, especially when assessments and audits are involved. If every system owner invented their own control set, comparing systems would be impossible and compliance would become a debate about personal preferences. Baselines also help organizations budget and plan, because they can anticipate the types of safeguards required for systems in certain categories. The baseline is a starting point, not a ceiling, and it is not meant to be swapped out casually. Once you accept that, identifying baseline controls becomes an exercise in mapping your system’s category and environment to the framework’s predefined set.
Most control frameworks organize controls into families or domains that cover recurring themes, because the same types of problems show up again and again. One family might focus on access control, another on configuration management, another on incident response, another on audit logging, and so on. These families exist because risk is not one single thing; it is a collection of failure modes that can happen at different points in a system’s life. People can misuse access, software can be misconfigured, systems can drift over time, and incidents can occur even with good defenses. A baseline tries to cover the basics across these areas so you do not end up with a system that has strong encryption but no logging, or strong authentication but no patching process. When you explain why a baseline exists, you are often explaining why each of these families matters, and how they collectively support confidentiality, integrity, and availability outcomes. This is also where your earlier security objectives work becomes useful, because you can link control families to the objectives they support.
To identify the baseline controls correctly, you first confirm which baseline applies under your chosen framework for the system’s impact level and any other classification factors the framework uses. Some frameworks use a small set of baselines like low, moderate, and high, while others may have additional profiles based on system type, environment, or regulatory scope. You do not pick a baseline because it feels reasonable; you pick it because the framework’s rules say it applies. This is a big part of defensibility, because auditors and assessors care that you followed the established method. Once you know the baseline, you can list the controls and sub-controls that are included, but more importantly, you can group them mentally by what they are trying to accomplish. Controls are often interdependent, and the baseline expects that the set works together, not as isolated items. Understanding the grouping helps you avoid implementing one control in a way that undermines another.
Let’s talk about access control as an example family, because it is one of the easiest to understand in terms of why it exists. Access control controls exist because most meaningful security failures involve someone doing something they should not be able to do, whether that someone is an outsider, a malicious insider, or an honest employee who made a mistake. Baselines include access control requirements to establish who can access the system, what they can access, and what they can do, and to ensure that access decisions are consistent and reviewed. Without access control expectations, confidentiality collapses quickly, but integrity and availability can also be harmed, because unauthorized changes can break systems and unauthorized activity can consume resources. Frameworks also know that access tends to creep over time, because people change roles and projects evolve, so baselines often include periodic review requirements. The why is straightforward: unmanaged access becomes invisible risk, and frameworks are designed to make invisible risk visible and controlled.
Audit and accountability controls are another family that beginners sometimes undervalue until they see how incidents are actually investigated. Logging controls exist because you cannot manage what you cannot observe, and you cannot prove what happened if you did not record it. Baselines require audit records so you can detect misuse, support investigations, and demonstrate compliance. They also require log protection because logs themselves become sensitive, since they can reveal user actions, system structure, and sometimes personal information. A baseline is not trying to turn every organization into a surveillance machine; it is trying to ensure that when something goes wrong, you have a reliable trail. Without auditability, you can have strong access controls and still fail to notice a compromise, or you might notice it but be unable to scope it. In terms of framework intent, audit controls support integrity by making tampering detectable, support confidentiality by enabling detection of unauthorized access, and support availability by supporting troubleshooting and recovery.
Configuration management controls exist because systems do not stay fixed after they are deployed, and unmanaged change is one of the most common causes of security and operational failures. Frameworks include baseline expectations for knowing what components exist, keeping configurations in known-good states, managing changes deliberately, and preventing unauthorized modifications. The why is that security is not a one-time setup; it is ongoing control of a moving target. If you cannot tell what version of software you are running, what settings are applied, and what changes were made, you cannot reliably protect the system or respond to vulnerabilities. Configuration drift can quietly disable security settings, open ports, weaken authentication rules, or break monitoring. Baselines push organizations toward a repeatable discipline where changes are documented and reviewed, because that discipline reduces both security incidents and operational outages. It is one of those areas where security and reliability are deeply intertwined.
Incident response controls are in baselines because frameworks assume incidents are inevitable, even in well-managed environments. The baseline is not pessimistic; it is realistic about complexity and human error. Incident response expectations exist to ensure that the organization can detect, analyze, contain, and recover from events in a coordinated way, rather than improvising under stress. Without incident response planning, teams waste time arguing about who is in charge, what the priority is, and what actions are allowed, which can worsen damage. Baselines often expect incident handling procedures, communication paths, and lessons-learned activities, because repeating the same incident over and over is a sign of unmanaged risk. This family supports availability because it helps restore service, supports integrity because it helps correct and validate system state, and supports confidentiality because it helps stop ongoing exposure. The why is that response capability is part of protection, not an afterthought.
Risk assessment and risk management controls exist in baselines because frameworks do not want security decisions to be made purely by habit or fear. The baseline expects that you periodically assess risk, consider threats and vulnerabilities, and update your controls and plans accordingly. The why is that environments change, new vulnerabilities appear, missions evolve, and systems get used in ways designers did not expect. A framework that ignored this would be outdated as soon as it was printed, because it would assume static conditions. Baselines typically include requirements for periodic assessment, documenting assumptions, and tracking remediation actions, because these create a feedback loop that keeps security aligned with reality. For a beginner, it helps to think of this as the framework insisting that you keep asking, is our protection still appropriate, and can we prove we are paying attention. It is also part of what makes compliance defensible, because you can show a record of risk decisions rather than a one-time statement.
Contingency planning and resilience-related controls exist because availability is often treated as a business requirement first and a security requirement second, but frameworks treat it as part of protection. Baselines include expectations for backups, recovery planning, and testing because data loss and downtime are common outcomes of both attacks and accidents. Ransomware is a dramatic example, but simple hardware failures, software bugs, and human mistakes can also cause serious outages. The why here is that the organization must be able to restore operations to meet mission needs, and the ability to recover reduces the impact of many incidents. Frameworks usually expect that backups are protected and that restoration is practiced, because an untested backup plan is often a comforting story rather than a real capability. This family ties directly to availability objectives and can also support integrity by enabling restoration to a known-good state. A baseline is essentially saying that if your system matters, you must be able to bring it back.
Awareness and training controls appear in baselines because people are part of the system, whether we like it or not. Frameworks include training expectations because many incidents start with misunderstanding, carelessness, or manipulation of users. Training is not a magical shield, and frameworks know that, but a basic level of awareness reduces predictable errors like mishandling sensitive information, reusing weak credentials, or ignoring security warnings. The why is that controls often depend on people following procedures, and procedures do not work if no one knows they exist. Training also supports accountability, because it sets expectations and reduces the excuse of I did not know. In governance work, training is also a form of evidence that the organization is taking reasonable steps, which matters in audits and in incident aftermaths. Baselines include it because ignoring the human element leads to security that looks good on paper but fails in practice.
As you identify baseline controls, you should also understand that frameworks often include controls that feel administrative or documentation-heavy, and those exist for a reason too. Documentation is not just bureaucracy; it is how organizations make security repeatable and auditable. When a control requires a policy, a procedure, or a record, the intent is usually to make the behavior consistent across time and across personnel changes. If a key employee leaves, the system should not become unmanageable because knowledge was only in someone’s head. Documentation also supports assessments, because assessors need to see not only that a setting exists today, but that there is a process for keeping it correct tomorrow. This does not mean you produce endless documents; it means you can point to a clear, maintained source of truth for how the organization manages the system. The baseline is pushing the organization toward maturity by insisting on repeatable behaviors, not one-off heroics.
By the end of this lesson, the core skill is that you can identify the correct baseline controls under your chosen framework and explain why the baseline exists, in terms of predictable risk patterns and desired outcomes. You understand that baselines create consistency, defensibility, and a common minimum across systems of similar impact, and you can explain how control families work together to support confidentiality, integrity, and availability. You can also resist the two most common traps: treating baselines as arbitrary checklists and treating them as optional suggestions. Instead, you see them as a structured starting point that embodies the framework’s logic and history. That perspective will make the next steps, inherited controls, applicability, and tailoring, much easier, because you will be working with the baseline’s intent rather than fighting it.
