Every system in your CUI boundary needs a documented baseline. That’s the approved, secure state that all systems should match. Without it, you’ve got machines configured however the last person who touched them felt like it. The other half of this practice is inventory: you need to know what systems exist, what’s on them, and whether they’re in compliance.
What the assessor is actually evaluating
The assessor is looking for two things:
Baseline configuration documentation. Not just “we have secure settings.” Can they see the actual baseline? Is it based on industry standards like CIS Benchmarks or DISA STIGs? Are the settings enforced (through Group Policy, Intune, or other mechanism)?
A current system inventory. They’ll ask how many systems are in scope. Then they’ll spot-check: “Show me the workstations in your Intune. Now show me your inventory list. Do they match?” If you have 18 devices in Intune but your spreadsheet says 12, that’s a failure.
Baseline configurations
Your baseline should include:
- Operating system version and patch level
- Security settings (firewall, antivirus, encryption)
- Disabled services (anything not needed)
- Installed software (approved applications only)
- Group Policy settings or Intune configuration profiles
- How to verify a system is in compliance
If you’re using Intune or Azure AD, your baseline is the set of configuration profiles, compliance policies, and conditional access policies pushed to devices. That’s documented, it’s enforced, and the assessor can see the actual settings. But you also need a laptop build sheet: a documented process for how a new machine gets set up. Standard software to install, approved applications list, the build process from bare metal to ready-for-user. This is the physical counterpart to the Intune profiles.
If you’re on-premise with Group Policy, document the GPO settings in each OU. Screenshot the settings or export them. That’s your baseline.
Whether you reference CIS Benchmarks, DISA STIGs, or your own internal standard, the assessor mainly cares that what’s documented matches what’s deployed. In practice, the specific reference framework hasn’t come up as a sticking point. What matters is that your SSP says “we do X” and your systems actually do X.
System inventories
Your inventory must include every hardware device and network device in the CUI boundary:
- Workstations, laptops, servers
- Network switches, firewalls, routers
- Printers, scanners, anything with an IP
- Make, model, OS, serial number
- Assigned user or location
- Software inventory: what’s approved to be installed on each class of device
The inventory has to be current. An Excel spreadsheet from two years ago is not current. If you’re using an RMM tool or Intune, pull live data. That’s current. Keep the exported list on file at least quarterly. If you decommission hardware, remove it from the list.
Software inventory and approval process. You need a list of approved software and a process for how new software gets approved. The assessor can and will spot-check. If they’re screen-sharing with someone during the assessment and see an unfamiliar application icon on the desktop, they can ask about it: is it approved? Where’s the documentation? Having a software approval process with tracking (even just a simple request-and-approval in your ticketing system) is the answer. This is one of those things that’s easy to overlook and can create a finding if you don’t have it.
Baseline Configurations: We maintain baseline configurations for all systems through Group Policy and Intune profiles. Baselines are derived from CIS Benchmarks and DISA STIGs, tailored to our operational requirements. Each baseline includes OS version, security settings, required software, disabled services, and firewall rules. Baselines are reviewed at least annually and updated through change management when security requirements change.
System Inventory: We maintain a current inventory of all hardware and software in the CUI boundary using Intune reporting and manual audit. The inventory includes workstations, servers, network devices, and associated software. The inventory is exported and reviewed at least quarterly to identify new systems, decommissioned hardware, and unauthorized software.
How to present your evidence
Pull up your baseline configuration. If you use Intune, show the configuration profiles and what they enforce. Screenshot the key settings. If you use Group Policy, export the GPO settings or show the console with the actual rules applied.
Pull up your system inventory. Show that it’s current. If the assessor asks “how many systems are in scope,” you should be able to answer immediately from your inventory. Demonstrate that the inventory matches your Intune or Active Directory user count. Pull a sample device and verify it’s in both the inventory and actually deployed.
Common failures
No documented baseline. You have secure settings, but nothing written down. You can't show the assessor what the baseline is. They can't tell if systems actually follow it.
Baseline exists but isn't enforced. You have a 10-page document describing the baseline. Machines are configured all over the place. Some follow it, some don't. If it's not enforced through policy, it's not a baseline.
Inventory doesn't match reality. The spreadsheet says 12 machines. Intune shows 18. The assessor asks where the extra 6 came from. You don't know.
Inventory is stale. Last updated two years ago. You've had staff turnover, new machines, retired machines. You're flying blind.
Baseline documented and enforced. CIS Benchmark as reference. Intune profiles or GPOs actively pushing settings. You can pull a random system and confirm it's in compliance.
Current inventory with spot checks. Quarterly reviews. New systems added immediately. Decommissioned systems removed. Assessor pulls the inventory and it matches your live systems.
Change management connected. When baseline changes, there's a documented process. For a 15-person shop, that can be as simple as: the IT person reviews the change to make sure it won't break anything, makes the change, and tracks it in a ticket. As long as it matches what your SSP defines and it's tracked, you're good.
Q&A: What the assessor asks and what good answers sound like
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
If you use an MSP/MSSP
If your MSP manages Intune or Group Policy, get documentation of the baseline configurations they enforce. You’re still responsible for the baseline. Know what policies they’re applying and why. Keep a copy of the baseline in your own records. For inventory, get a monthly or quarterly export from their RMM. Add that to your records. You present both to the assessor.
NIST SP 800-171 Rev 2: 3.4.1. Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.