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. Your baseline also ties to patch management and maintenance. MA.L2-3.7.1 covers maintenance, and patching is one of the key ways you keep systems aligned with the baseline.
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.
Your inventory also feeds into your CUI boundary definition. That’s where SC.L2-3.13.1 comes in: you need to know what’s in scope, what’s out, and where the boundary is. A current inventory is the foundation for that boundary.
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
- Baseline configuration document with OS, security settings, and software
- Intune profiles or Group Policy objects showing enforced settings
- Current system inventory with hardware and software details
- Quarterly inventory review records
- Spot-checks showing systems match baseline configuration
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.
Screenshots of config baselines aren't enough. Assessors want live demos. They want to see you navigate the actual console, not a PDF from last quarter. Have the admin portal open and ready. When assessors recognize your MSSP's standard build methodology across clients, trust accelerates. Consistency is a credibility signal.
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.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
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.
Q&A: What the assessor asks and what good answers sound like
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.