06 Configuration Management in HITRUST assessments

What HITRUST 06 Configuration Management asks your systems to prove

If you are preparing an e1, i1 or r2 assessment, this domain asks you to show that the systems and services in scope run on approved secure baselines, that changes to them are reviewed and authorized, and that their actual configuration matches what you say it is. Assessors will not accept a policy that describes good configuration as proof. They will sample real systems, compare their settings with the baseline you documented, and trace a sample of changes back to an approval and a test record.

The domain is hard for three recurring reasons. The first is drift, where a server, container image or cloud resource is built correctly and then changed by hand so that its running settings no longer match the approved baseline. The second is changes that bypass review, such as emergency fixes applied directly on a host and never recorded. The third is ownership. Where a cloud or managed-service provider maintains baselines for its platform, HITRUST's inheritance example shows that the customer still owns misconfiguration of its own tenancy and applications. Confirm exactly which settings your provider's reports cover before you claim them as inherited, and document the remaining ones as your own.

This domain also carries AI security requirements when you add the AI security assessment, since HITRUST's AI Security Assessment help page places those requirement statements here. Scoring is shared with the other 18 domains. Under the Assessment Handbook v1.1, the e1 and i1 must average at least 83 across the core requirement statements in each domain, and the r2 must average at least 62 in each domain across all its statements. Because each domain is scored on its own, a weak configuration program can hold back the whole certification even when other domains are strong, so plan evidence collection for this domain early.

Which systems, teams and providers fall under configuration management scope

Configuration management scope is set by which systems, accounts, applications, teams and providers can change or depend on the in-scope environment. Each decision below shifts who owns a baseline, who evidences it and what the scope statement must name explicitly.

In-scope servers and endpoints

Every server, virtual machine and endpoint that stores, processes or can reach in-scope data needs a defined secure baseline and a record of its configuration. Build images, golden templates and hand-built hosts all count, so the inventory should come from a source that reflects what is actually running. Confirm whether the scope statement lists hosts by name, by group or by build, and whether drift between the baseline and the running state is checked on a stated schedule. Tools such as Wazuh's Security Configuration Assessment can evidence endpoint checks against YAML policies, but the scope statement must still name the population those checks cover.

Cloud accounts and tenancies

Cloud accounts, subscriptions and tenancies are where most configuration decisions now sit, including network rules, storage permissions and logging settings. HITRUST's inheritance example treats configuration as moderately inheritable: the provider maintains baselines for its managed services, but misconfiguration of the customer's own tenancy stays with the customer. Confirm which accounts are in scope, which managed services are inherited from the provider and which settings the organization configures itself. The scope statement should separate these clearly so an assessor does not have to infer ownership.

Applications and their dependencies

Application configuration covers runtime settings, feature flags, secrets references, container images and the libraries and services an application depends on. A change to a shared library or base image can alter many applications at once, so dependencies belong in scope even when the application team does not own them. Confirm whether the scope lists each application and its dependency chain, how container and image baselines are versioned, and where application configuration is stored and reviewed.

Change-owning teams

Any team that can alter configuration in scope is a scope decision, including platform engineering, application developers, network operations and anyone with console or infrastructure-as-code write access. Teams that change configuration outside the standard pipeline often create the gaps assessors test first. Confirm which teams are named as change owners, who approves changes, and how emergency changes are recorded and reviewed afterward. GLPI's Assistance module, which handles tickets, problems and changes under ITIL practices, is one way to record those decisions, but the scope statement should name the teams it covers.

Managed service providers

Managed service providers that patch, administer or configure systems in scope change who performs configuration work, but not who answers for it to the assessor. Their baselines may be inherited, while their access paths, change tickets and remote administration remain part of the customer's evidence. Confirm the provider's responsibilities in writing, which of their configuration records the organization can obtain, and how the provider's changes flow into the organization's change review. Where a provider's controls are relied on, the shared responsibility matrix should show exactly which configuration settings are covered.

AI components when the AI security assessment applies

When an organization pursues the AI security assessment, HITRUST places AI security requirement statements in this domain, so model serving configuration, prompt and tool settings, and AI gateway rules can enter configuration scope. These components often change faster than traditional systems and may be owned by data science or product teams. Confirm which AI services, model endpoints and agent tool permissions fall inside the assessed boundary, who approves changes to them, and how their baselines are versioned. Whether a particular AI deployment falls under the assessment depends on the scope agreed with the assessor and the chosen assessment type.

How an assessor tests configuration management in the fieldwork window

This table compares how an authorized External Assessor typically tests the 06 Configuration Management domain, the evidence it asks for and the findings that often appear. Read it as a preparation checklist: the organization owns its baselines and change records, while the assessor independently samples them within a fieldwork window of at most 90 days, and HITRUST reviews the work before any report issues.

Test area	What the assessor typically does	Evidence requested	Common findings
Baseline documentation	Reviews approved secure configuration baselines for each in-scope system type and checks they cover operating systems, databases, network devices and cloud services.	Current baseline documents, version history, owner approvals and the date of last review.	Baselines exist for servers but not for containers, SaaS tenants or network devices in scope.
Baseline to production match	Selects sample systems and compares their live settings against the documented baseline.	Configuration exports, configuration management tool output or hardening script results for the sampled systems.	Production settings differ from the approved baseline with no record of why.
Automated scan output	Inspects configuration assessment scan results for in-scope endpoints and servers, and checks how findings are triaged.	Scan reports, scan scope definitions, policy versions used and remediation tickets linked to failed checks.	Scans cover only part of the in-scope estate, or failed checks stay open without a documented decision.
Change sample traced to deployment	Selects a sample of changes and traces each from request and approval through testing to the deployed state.	Change tickets, approvals, test results, deployment logs and post-change verification records.	Changes are deployed without an approval on file, or the approval was given after deployment.
Exception handling	Looks for deviations from baselines and checks that each one was assessed, approved and tracked to closure or review.	Exception register, risk acceptance records, compensating controls and review dates.	Undocumented exceptions, or exceptions approved by someone without authority to accept the risk.
Ownership of configuration in shared services	Confirms which configuration settings the organization controls and which a provider maintains, using the agreed responsibility matrix.	Shared responsibility matrix, provider baseline reports and contract terms covering configuration.	The customer assumes a provider maintains settings the provider does not control, such as application or tenancy configuration.
AI security requirements (if added)	Where the AI security certification is in scope, checks configuration requirements for AI systems and their supporting components in this domain.	Documented configuration of AI platforms, model and component inventories and change records for AI components.	AI components are missing from baselines and change control because they were treated as application code only.

Which configuration evidence passes an assessment and how to keep it current

Assessors test configuration management by checking whether the baseline, the scan results, the change history and the exceptions agree with each other and with the systems as they run. No single artifact carries the domain, so the cards below describe a set of records that support one another. Each card also notes how to keep its record current between assessments, since a snapshot taken for the assessment window rarely shows sustained control.

Approved baseline standards

A baseline is the documented secure configuration for each system class in scope, such as operating system images, container base images, network devices and cloud accounts. Assessors look for baselines that name an owner, a version and an approval date, and for evidence that the systems in the inventory were built or checked against them. Keep baselines in version control, export the approved version with a date each quarter, and record owner sign-off on every revision. Confirm that each baseline matches the system class it covers.

Configuration scan reports

Scan reports show which in-scope endpoints and servers deviate from their baseline, and the report alone does not show whether anyone acted on the deviations. Wazuh's Security Configuration Assessment checks files, directories, registry keys and running processes against YAML policies, mostly built on CIS benchmarks and extendable with custom policies, and it recommends remediation. Retain each scan export with its date and policy version, and keep the remediation tickets that link each failed check to a fix or an accepted exception.

Change requests with approval records

Change records show how configuration changes to in-scope systems were requested, reviewed, tested and approved before they went live. Assessors sample changes across the period and check that each has a requester, an approver separate from the implementer where practical, a test result and a closure date. GLPI's Assistance module follows tickets, problems and changes under ITIL practices, and its history can serve as the record. Keep the ticket history intact, and do not allow changes to be closed without their approval field completed.

Exception register and compensating controls

An exception register lists each system or setting that departs from the approved baseline, the reason, the risk owner, the compensating control and the review date. Assessors check that exceptions are approved, time-limited and reviewed, and that compensating controls exist and are tested. An exception with no owner or no expiry usually reads as an unmanaged deviation. Export the register on a fixed schedule, keep superseded entries, and record each renewal with the owner's sign-off.

Policy compliance dashboards

Compliance dashboards show the current pass or fail state of configuration policies across the fleet, which helps show how well the baseline holds day to day. Fleet policies are yes or no questions asked of devices as osquery queries, and its policies page shows which devices in each fleet pass or fail each policy. A dashboard is a live view, so the assessment record needs dated exports, with the policy definitions attached so an assessor can see what each pass or fail meant at the time.

AI component configuration records

If the AI security assessment is in scope, HITRUST's AI Security Assessment help places AI security requirement statements in this domain, so the configuration records must cover AI components too. These include model serving endpoints, vector stores, agent tool permissions and the prompts, guardrail settings and system configurations that shape their behavior. Record each component in the inventory with its configuration version, owner and approval, and keep a change history for each. Confirm the exact requirement statements that apply with HITRUST's current AI Security Assessment guidance before you collect evidence.

How to build secure baselines and change control in the right order

This sequence moves from knowing what is in scope, to setting a secure baseline for each system class, to proving that changes are controlled and deviations are tracked. Each step produces an artifact an assessor can sample, so the evidence pack reflects how the environment is actually managed.

Confirm the in-scope asset inventory
Start by listing every system, service, cloud account, container platform and network device that falls within the assessed scope, and record its owner, purpose and system class. Engineering and IT operations own the list, and the security lead reviews it for gaps such as shadow services or unmanaged endpoints. The step is done when the inventory is reconciled against the scope statement and each asset has a named owner. This inventory is the foundation for every baseline and sample that follows, so an incomplete list will surface later as a finding.
Define baselines for each system class
Group in-scope assets into system classes such as workstations, Linux servers, Kubernetes clusters, databases and SaaS administration consoles, then write a secure configuration baseline for each class. Base the settings on a recognized hardening benchmark where one fits, and document any deviations with the reason. The output is an approved baseline document per class, signed off by the system owner and a security approver, with a version number and review date. Confirm with your assessor which benchmark sources they accept before you commit to one.
Set up configuration scanning and policy checks
Deploy an automated tool that compares live systems against the approved baselines and reports drift. Open-source options include Wazuh Security Configuration Assessment, which uses YAML policies largely based on CIS benchmarks and accepts custom policies, and Fleet, which answers yes or no policy questions through osquery and shows passing and failing devices per fleet. Confirm that each tool covers every system class in the inventory. The step is complete when scan results for a sample of assets are stored, and failing checks create tracked tickets rather than sitting unread in a dashboard.
Define the change workflow with approval and rollback
Document how a configuration change is requested, assessed for security impact, approved, implemented, tested and reversed if it fails. A ticketing system such as GLPI, whose Assistance module supports ITIL-based change handling, or Zammad for request intake, can hold each record. Name the approvers by change type, and state the rollback method for each class of change. The output is a written change procedure and a working ticket template. Ask your readiness reviewer whether emergency changes need a separate path, since assessors test those cases separately.
Record and manage configuration exceptions
Where a system cannot meet its baseline, record a formal exception that names the control gap, the business reason, the compensating measure, the risk owner and a review date. Route each exception through the risk process so the accepting manager sees it. The output is an exception register that links each entry to the affected asset and the scan finding that triggered it. Reviewing the register regularly shows that deviations are known and decided, not forgotten. Exceptions that never close are a common reason assessors question the configuration program.
Produce the first evidence pack for readiness review
Assemble the artifacts that show the program operates: the asset inventory, approved baselines, scan reports across sampled systems, a set of closed change tickets with approvals and rollback notes, and the exception register. Check that dates, version numbers and owners are consistent across all items. Then ask an independent readiness reviewer to walk through a sample, since an outside view often finds gaps the internal team has stopped noticing. Your implementation partner can prepare the pack, but only the independent assessor tests and reports on it. Confirm the review scope and deliverables in writing before the review starts.

What meeting configuration management costs in money and effort

This table compares the cost components of meeting the 06 Configuration Management domain, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a written scope before asking for quotes, since the largest variables are the number of in-scope systems and how much baseline work already exists.

Cost component	One-time or recurring	What drives it up or down	Open-source effect and what to request in a quote
Tooling or licenses	Recurring	Number of endpoints and servers in scope, and whether configuration scanning is bought or built	Wazuh configuration assessment and Fleet policies can replace some license spend, but the organization still pays for hosting, storage and admin time. Request the tool list and who operates each one.
Engineering time to write baselines	One-time, then periodic updates	Number of distinct system types, how many hardening benchmarks are adopted, and how well images are already standardized	Baseline policies can start from published benchmarks, but each baseline must be tailored and approved. Request named baseline deliverables per system type.
Scanning and remediation effort	Recurring	Scan frequency, false positive rates, and how many misconfigurations exist at the start	Open-source scanners report deviations but do not fix them. Ask the partner to state who triages findings and what remediation is included.
Change process overhead	Recurring	Volume of changes, approval steps, and whether change records are kept in a ticketing system	GLPI Assistance or Zammad can hold change tickets, but the process must be defined and followed. Ask what change workflow and approval records are delivered.
Evidence upkeep	Recurring	How often evidence is collected, how many systems are sampled, and how much is automated	Scheduled exports from scanners and ticket systems reduce manual collection. Request the evidence list and collection frequency in the scope.
External readiness review or testing	One-time per assessment cycle	Maturity of current controls, number of gaps, and whether a readiness review is included	Readiness work prepares evidence but does not issue results. Request a written statement of what the review tests and what it excludes.
Assessor fieldwork	Recurring per assessment	Assessment type, scope size, and the assessor's fieldwork window, which is at most 90 days for e1, i1 and r2 (HITRUST Assessment Handbook v1.1)	Only an authorized External Assessor performs fieldwork, so this fee is paid to that firm and is separate from implementation work. Ask the assessor for a written fee and timeline.

Which open-source tools produce configuration evidence, and their license caveats

Configuration Management evidence usually comes from four kinds of tooling: baseline checks on endpoints, device policy queries, change tickets and customer request intake. The four open-source products below each cover one of these, and each carries a license term that affects how an organization can deploy and modify it.

Wazuh configuration assessment

Wazuh's Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies. These policies are mostly based on CIS benchmarks, can be extended with custom policies, and check files, directories, registry keys and running processes. Each finding comes with remediation advice, which gives the assessor a dated record of baseline drift. Licensed under GPL-2.0-only, so confirm with counsel how modified policies and internal distribution of agents fit your obligations, and confirm with your assessor which benchmark versions they expect you to baseline against.

Fleet policies for device state

Fleet policies ask each device a yes or no question written as an osquery query, such as whether disk encryption or a host firewall is enabled. The policies page shows which devices in each fleet pass or fail each policy, so the failing list becomes a remediation queue and a record of compliance over time. Fleet is MIT licensed, which keeps redistribution and modification simple. Confirm that the queries you rely on are supported on every operating system in scope and that your assessor accepts query results as configuration evidence.

GLPI change management

The GLPI Assistance module tracks tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. For Configuration Management, the change record is the evidence that a baseline change was requested, approved, implemented and reviewed. GLPI is licensed under GPL-3.0-or-later, so any modifications you distribute carry copyleft obligations. Confirm that approval steps, retention of closed change records and separation of duties match your written change control procedure before an assessor samples them.

Zammad customer change requests

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. It only supports Configuration Management where customers submit change requests that affect the in-scope environment, since those requests need a traceable path into the change process. Zammad is licensed under AGPL-3.0-only, and running a modified version as a network service can trigger source disclosure duties for users. Confirm whether your customer-facing workflow is in scope at all, and whether your assessor expects those requests to be linked to the change records held in your change tool.

Who does what: your team, an implementation partner and the assessor

Your organization owns the configuration management controls in the assessed scope, and no partner or tool can accept that ownership for you. Your team decides what a secure baseline looks like for each system, approves changes to those baselines, and decides which deviations are acceptable and for how long. Those decisions must be written down, dated and traceable to a named owner, because an assessor will ask who approved what and when.

Baseline ownership: Name an owner for each system or service type, and record which benchmark or internal standard the baseline follows.
Change approval: Approve changes to baselines and production configurations through a documented process, with a record of the requester, reviewer and outcome.
Exception acceptance: Decide which failed checks are accepted risks, record the compensating measure, and set a review date.
Scan result review: Review configuration scan output on a set cadence, assign remediation, and confirm that fixes were made.
Shared responsibility: Confirm which baseline items your cloud or hosting provider maintains and which remain with you, using the provider's documentation.

Before an assessment, check that every baseline has a named owner, every exception has an approver and an expiry date, and every scan finding has a recorded disposition.

Where configuration management fails in assessments and how to close each gap

Configuration management failures in a HITRUST assessment rarely come from missing tools. They come from gaps between what the organization documents, what runs in production and what it can prove. Each card below names one gap, the action that closes it and the evidence an assessor will ask to see.

Baselines that differ from production

A hardening standard that exists only as a document does not show the assessor what the systems actually run. Compare the approved baseline for each system class against live settings on a sample of in-scope hosts and containers, and record each deviation with its reason. The evidence is the approved baseline, a dated scan of production against it and a list of accepted deviations.

Changes made outside the ticket workflow

Direct edits on servers, consoles or cloud accounts bypass the approval record that an assessor samples. Route production changes through a change ticket with an approver, a rollback plan and a closure step, and check periodically for changes that have no ticket. The evidence is a sample of changes traced from request to approval to post-change verification.

Exceptions with no expiry

A deviation accepted once and never reviewed becomes the permanent configuration. Give every exception a named owner, a documented risk acceptance, a compensating control and a review date that forces a decision. The evidence is an exception register showing open, closed and renewed items, with approvals dated before each exception took effect.

Scan results with no remediation trail

Failed configuration checks that are never assigned or closed look like a control that is not operating. Feed each failing policy into a ticket with an owner and target date, and record the outcome, whether fixed, accepted or false positive. The evidence is the policy results over time alongside the tickets that show what happened to each failure.

Inherited settings assumed covered

HITRUST's inheritance example treats Configuration Management as moderately inheritable: a provider maintains baselines for its managed services, but misconfiguration of the customer's tenancy and applications stays with the customer. Map each inherited setting to the provider's report, then confirm the customer-side settings separately. The evidence is a shared responsibility matrix with the customer-owned configuration items named and tested.

AI components with no configuration record

The AI security certification adds requirement statements to this domain, so models, prompts, inference endpoints and agent tool permissions need the same baseline and change discipline as other systems. Inventory each AI component, record its version and settings, and bring model or prompt changes through the change process. The evidence is an AI component inventory with configuration records and change tickets for each update.

Questions buyers ask about configuration management effort and outside help

What drives the effort in configuration management the most?

The biggest driver is how many systems in scope have a documented secure baseline and how much of that baseline is actually enforced and evidenced over time. Assessors look for baselines for each system type, proof that changes follow a controlled path, and evidence that drift is detected and corrected. Organizations with many hand-built servers, inconsistent cloud accounts or undocumented exceptions usually spend the most time before fieldwork starts. Asking for a scope list of systems and a count of distinct build types in the quote will show how much work sits in front of you.

Can one internal team handle HITRUST configuration management without outside help?

Often yes, if the team already owns its baselines, change tickets and configuration tooling and has someone who knows how assessors sample evidence. Outside help is most useful for readiness gaps, mapping existing evidence to requirement statements and preparing systems and records before the assessor arrives. An external assessor must perform the validated assessment, and HITRUST performs central quality assurance before issuing reports, so the internal team cannot replace that step. Confirm internally whether you have capacity for a readiness review and a fieldwork period in the same quarter.

How long can HITRUST fieldwork run for configuration management?

The assessor's validated assessment fieldwork window is at most 90 days for e1, i1 and r2 under the HITRUST Assessment Handbook. That window is a ceiling for the whole fieldwork, not a target, and the time your team spends preparing evidence before it starts is separate. Configuration evidence that is scattered across tools tends to slow the assessor down because each sample needs manual retrieval. Ask your assessor how they plan to sample configuration records and which artifacts they will request first, so you can have them ready.

What does configuration management need from engineering and change owners?

Engineering owns the baselines and their enforcement, while change owners own the approval, testing and recording of changes to in-scope systems. Engineers need to show how builds are standardized, how configuration checks run and how deviations are handled. Change owners need to show that requests, approvals and post-change reviews are recorded consistently. Assign named owners for each system type and agree on who signs off on exceptions before the assessment begins, because unclear ownership is a common reason evidence goes missing.

How does inheritance from a cloud provider change configuration management scope?

In HITRUST's OCI inheritance example, configuration management is moderately inheritable: the provider maintains baselines for its managed services, while misconfiguration of the customer's tenancy and applications stays with the customer. In practice, you can reuse the provider's results for the infrastructure it manages, but you still need your own baselines for virtual machines, containers, identity settings and application configuration. Review the provider's shared responsibility documentation and check which configuration items it actually covers before you narrow your scope. The inheritance terms are a question to confirm with your provider and assessor, not an assumption.

What does the AI security assessment add to configuration management?

HITRUST's AI Security Assessment help page places AI security requirement statements in the configuration management domain, so an e1, i1 or r2 that includes the AI security certification adds requirements here. These typically concern how AI systems, models, prompts, tools and their supporting services are configured, approved for use and changed under control. Teams that already run change control for applications will have a head start, but they should check whether AI components are in the inventory and baseline at all. Confirm the exact requirement statements applicable to your scope with the assessor before planning evidence.

What should I ask for in a quote for configuration management work?

Ask for a written scope that lists the systems, cloud accounts and applications covered, the baselines to be built or reviewed, and the evidence each deliverable will produce. Request the assumptions behind the effort, including inheritance decisions, the number of system types and whether you will need help with change control records. Ask which tasks are one-time, such as building baselines, and which recur, such as monitoring, reviewing exceptions and re-running checks before renewal. DeployOpen works from a written scope and does not publish a price list, so the quote will follow from the scope you agree on.

Which open-source tools can produce configuration evidence?

Several self-hosted tools can produce evidence that supports this domain, though none of them makes an organization compliant on its own. Wazuh's Security Configuration Assessment scans endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom checks. Fleet policies ask devices yes or no questions as osquery queries and show which devices pass or fail each policy. GLPI's Assistance module tracks changes following ITIL practices, which helps show a controlled change record. Confirm each tool's fit with your environment and your assessor's expectations before relying on it.

How DeployOpen scopes, implements and prepares configuration evidence

DeployOpen works on 06 Configuration Management as a self-hosted implementation partner inside your own cloud accounts, data centers or air-gapped networks. We prepare the baselines, change records and configuration evidence your organization owns, while an independent HITRUST External Assessor performs the validated assessment and issues any report.

How we scope

Agree in writing which systems, services and AI components fall inside the configuration management scope.
Map which configuration baselines your organization owns and which a managed provider maintains for its services.
Confirm whether the AI security requirements apply, since they add statements to this domain.
Record the scope, deliverables and timelines in a fixed-scope document before any work starts.

How we build

Define secure baselines for in-scope operating systems, services and applications, referencing common benchmarks where suitable.
Deploy open-source configuration assessment tooling that checks endpoints against written policies and flags drift.
Connect change requests to an ITIL-style ticketing workflow so every configuration change has an approver and a record.
Test that baseline checks detect deliberate misconfigurations before the evidence is relied on.

How we hand over

Document each baseline, its owner, its review cadence and the exception process for deviations.
Deliver exports of policy results, change tickets and remediation records organized for assessor sampling.
Provide a control-to-evidence map showing which artifact supports each requirement statement in the domain.
Walk your internal owners through running the checks and reviewing results without DeployOpen involved.

How we support

Offer ongoing support, upgrades and continuous testing of the configuration tooling as a retainer.
Update baselines and policies when your systems change or when a new CSF version alters the requirements.
Support your team during fieldwork by preparing evidence requests, though the assessor selects its own samples.