- A baseline is a defined reference state, not merely the vendor’s default settings.
- A change needs an understood purpose, effect and verification.
- Drift is a difference to investigate, not a conclusion about its cause.
Learning objectives
This lesson explains configuration management through a simple collaboration workspace. You will learn what a baseline represents, why changes need evaluation and how a difference between intended and actual settings becomes a question to investigate. The goal is to describe a repeatable way of understanding system state rather than memorizing a particular product's settings menu.
Use an invented configuration record for practice. Do not change real security settings to create an example. A paper scenario with three settings and a fictional change request provides enough detail to understand the reasoning and its limits.
- Explain the purpose of an approved baseline.
- Distinguish an intended change from unexplained drift.
- Connect a change decision to implementation and verification.
Know what your reference state means
A baseline describes a defined configuration that the organization uses as a reference. It should be specific enough for responsible people to understand the intended state, its purpose and relevant version. It is not automatically the same as a product's factory default or a list of settings copied from another environment. A setting can have different implications depending on the work and connected services.
NIST SP 800-128 explains security-focused configuration management as part of managing systems and organizational risk. In this lesson, that guidance supports a general learning model. Real CMMC implementation still needs the applicable requirements and environment-specific decisions. A classroom baseline is an explanatory artifact, not a universal approved configuration for every contractor.
Follow a change from purpose to verification
Start with why the change is proposed and what it affects. Identify the relevant information flows, users, dependencies and expected behavior. Decide how the change will be reviewed, implemented and checked, including an appropriate recovery approach if the result is unsuitable. Record the decision and update the description after the implemented state is verified.
Drift means the actual state differs from the reference. The difference might reflect an authorized change that was not documented, an error, an unexpected update or another cause. Do not infer the cause from the difference alone. Investigate through the responsible process, then correct the state or the reference as appropriate. Rewriting the baseline merely to match an unexplained change hides the question instead of resolving it.
Worked example: a helpful sharing feature
In a hypothetical design team, the approved workspace configuration limits external invitations. A vendor update introduces a new link-sharing feature. An administrator enables it to make a demonstration easier, but the decision is not recorded and the team does not examine how the new links behave. Later, a learner compares the current settings with the baseline and finds the difference.
The learner identifies a change-review gap, not an automatic assessment outcome. The responsible team needs to determine what was enabled, why, who could use it and whether it fits the required operation. A controlled check can inform the decision. If the change is approved, the configuration record and instructions need updating; if it is unsuitable, the team follows its process to restore an appropriate arrangement.
Practice a small change record
Create a fictional request to add a new reporting feature. Describe its business purpose, affected users, information inputs and outputs, dependencies, proposed implementation and acceptance criteria. Include who can authorize the change and who can verify the result. Keep the record short enough to use, but specific enough that a different person could understand the decision later.
Now add a surprise: the feature sends diagnostic information to an external service. Explain which earlier assumptions need review. Do not assume a routine software update has no information-flow effect. The exercise teaches you to connect a configuration decision with the wider environment, including service relationships and user behavior, rather than treating settings as isolated technical details.
Self-check and answer
A learner finds that the current setting differs from the approved baseline. The learner immediately edits the baseline to match, explaining that the document should describe reality. What step is missing from that reasoning?
Answer: the learner has skipped evaluating the difference and determining whether the actual state is authorized and suitable. Accurate documentation matters, but changing the reference cannot by itself validate the underlying change. The responsible team should establish the cause, assess the effect, make an authorized decision and verify the resulting state. Only then can the baseline and related records reliably describe the approved arrangement.
Sources & further learning
Use primary sources and the current requirements relevant to your situation. This guide is a learning resource, not a contract-specific or assessment determination.
Learn how assets and external services fit into the environment
Build on this guide with a connected concept, then explain how the two ideas fit together.
Continue learningWhen the concept becomes a practical question
After practicing the concept, explore whether CMMC Pulsar fits your team’s readiness organization and evidence workflow.
Explore CMMC PulsarSelf-checks are educational reflection activities. They do not confer a credential, demonstrate compliance, or establish certification. Read our editorial approach.