Control of Operational Software

To meet the HITRUST “Control of Operational Software” requirement, you must prevent unapproved software from being installed on production systems and require documented management approval through formal change control for every production software installation. Operationally, this means an approved-software standard, technical controls that enforce it, and auditable change records that show who approved what, when, and why. (HITRUST CSF v11 Control Reference)

Key takeaways:

• Maintain an authorized software baseline for production, and block everything else by policy and technical guardrails.
• Route every production installation through formal change control with management approval and implementation evidence.
• Keep artifacts that prove both prevention (controls) and accountability (approvals, tickets, logs, and reconciliations).

“Control of operational software” is one of those requirements that sounds straightforward until an assessor asks you to prove it across servers, endpoints, cloud workloads, and third-party-managed systems. HITRUST CSF v11 10.h is explicit: you need procedures that control software installation on operational systems; only authorized software can be installed on production; and installation requires management approval via formal change control. (HITRUST CSF v11 Control Reference)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate that into three things you can defend: (1) a clearly defined scope of “production systems” and “software installation,” (2) a repeatable approval workflow that shows management sign-off before change, and (3) technical enforcement that makes “only authorized software” true in practice, not just on paper.

This page gives requirement-level implementation guidance you can put into your control library and hand to IT operations, cloud engineering, security engineering, and your service desk. It also includes the evidence package auditors usually want and the failure modes that trigger findings.

Regulatory text

HITRUST CSF v11 10.h states: “There shall be procedures in place to control the installation of software on operational systems. Only authorized software shall be installed on production systems, and software installation shall require management approval and follow formal change control procedures.” (HITRUST CSF v11 Control Reference)

Operator meaning (what you must be able to demonstrate):

1. You have documented procedures that govern how software gets installed on operational systems.
2. Your organization defines and maintains a set of “authorized software” for production.
3. Production software installs do not happen without management approval.
4. That approval occurs through a formal change control process, with records you can produce. (HITRUST CSF v11 Control Reference)

Plain-English interpretation

You must stop ad hoc installs in production. People cannot remote into a production server and “just install” an agent, package, library, admin tool, browser, or plugin because it’s convenient. If it’s going into production, it must be:

• on an approved list (or explicitly approved for that event), and
• implemented through change control with management approval.

This control is about reducing operational outages, malware risk, license violations, and configuration drift. It also reduces “mystery software” that becomes impossible to patch or support.

Who it applies to

Entities

• All organizations implementing HITRUST CSF controls. (HITRUST CSF v11 Control Reference)

Operational context (systems and teams)

This requirement applies wherever you run “operational systems,” especially:

• Production servers (on-prem and cloud IaaS)
• Production endpoints used for operations (jump hosts, admin workstations)
• Production platforms (managed Kubernetes worker nodes, VM scale sets, container hosts)
• Production SaaS/admin consoles where “installing software” includes enabling marketplace apps, plugins, extensions, or agents
• Third-party-managed production environments where your third party has install rights (you still need governance and evidence)

Practical scoping rule: If a system supports regulated workloads (for many HITRUST programs, that includes systems that store, process, or transmit sensitive health data), treat it as production for purposes of this control unless you have a defensible classification and segmentation model.

What you actually need to do (step-by-step)

1) Define “production,” “operational system,” and “software installation”

Write down definitions that match how your environment works. Keep them short and testable.

• Production system: systems supporting live business operations and/or regulated workloads.
• Software installation: OS packages, binaries, agents, libraries, container images, scheduled tasks that deploy binaries, and plugins/extensions in production admin tools.

Exam hangup to avoid: If your policy only mentions “servers” but your risk is in containers, cloud agents, and SaaS plugins, auditors will treat that as a scope gap.

2) Establish an authorized software standard (the allowlist)

Create and maintain an “Authorized Production Software List” (APSL). You can structure it as:

• Category (EDR agent, monitoring agent, backup agent, database client, SFTP tool)
• Approved product name/vendor
• Approved versions or versioning approach (exact versions or “supported current” with a patch policy)
• Approved deployment method (MDM, golden image, CI/CD pipeline, configuration management tool)
• Owner (business/technical) and reviewer (security/compliance)

Minimum operating requirement: a documented mechanism that distinguishes “authorized” vs. “not authorized” for production installs. (HITRUST CSF v11 Control Reference)

3) Put a management approval gate in front of every production install

You need a “management approval” step that is explicit in your workflow. In practice:

• For standard, low-risk installs (pre-approved items on the APSL), use a pre-approved standard change model with an identified manager as approver.
• For non-standard installs (new software, new agents, new plugins), require a normal change with business justification, risk review, and manager approval.

Management approval should be identifiable: name/role, date/time, and the scope of what was approved. (HITRUST CSF v11 Control Reference)

4) Route installs through formal change control

Your change record should include:

• Requestor
• System(s) affected (asset IDs, hostnames, cloud resource IDs)
• Software details (name, version, source)
• Implementation plan and rollback plan
• Testing/validation plan (how you confirm it works and doesn’t break production)
• Approvals (including management approval)
• Implementation evidence (logs, screenshots, pipeline run output, config management run)

This is the backbone of auditability for 10.h. (HITRUST CSF v11 Control Reference)

5) Enforce the procedure with technical controls (so it isn’t optional)

HITRUST 10.h is written as a procedural requirement, but auditors will test whether procedures are effective. Common enforcement patterns:

• Remove local admin rights on production systems except controlled break-glass.
• Privileged access management for production install actions (session logging helps).
• Application control / allowlisting on production servers and admin workstations where feasible.
• Golden images and immutable infrastructure: software arrives through images and pipelines, not interactive installs.
• Package repository controls: only approved repos; restrict who can add repos or install packages.
• Configuration management (desired state) to prevent drift and flag unauthorized packages.

6) Handle break-glass and emergency changes without breaking compliance

Emergency installs happen. Define:

• What qualifies as emergency
• Who can approve (on-call manager)
• Time window for retrospective documentation
• Evidence required after the fact (ticket, logs, reason, approval)

The key is that emergency is still change control. The sequence changes, but the accountability remains. (HITRUST CSF v11 Control Reference)

7) Cover third parties that can install in your production

If a third party administers production systems, your contract and operating model must require:

• Only authorized software
• Install requests through your change control (or an equivalent process you can evidence)
• Log access and installation actions available to you on request

Day-to-day, this becomes a due diligence and ongoing monitoring item: validate their change records and sample them during reviews.

Where Daydream fits naturally: Many teams track third-party access, change artifacts, and recurring evidence collection in spreadsheets and email threads. Daydream can centralize third-party governance artifacts (contracts, SOC reports, change evidence requests, and exception tracking) so you can produce a clean audit trail without re-chasing the same proof each assessment cycle.

Required evidence and artifacts to retain

Keep artifacts that show design, operation, and enforcement:

Governance

• Operational Software Installation Procedure (production scope, approvals, steps)
• Change Management Policy/Standard describing approval requirements
• Authorized Production Software List (with owners and review cadence)
• Exception process (temporary approvals, risk acceptance)

Operational records

• Sampled change tickets for production installs with management approval and implementation notes
• CAB/approval records (where applicable)
• Deployment pipeline runs or configuration management logs tied back to change tickets
• Privileged access logs for install actions (where tools support it)
• Break-glass/emergency change records and post-implementation review notes

Monitoring

• Periodic reconciliations: inventory of installed software vs. APSL, plus remediation tickets for unauthorized findings
• Evidence of removal actions for unauthorized software (ticket closure notes, uninstall logs)

Common exam/audit questions and hangups

• “Show me how you prevent engineers from installing unapproved software on a production host.”
• “Where is the authorized software list, and who approves additions?”
• “Give me three examples of production installs and prove management approved them before implementation.” (HITRUST CSF v11 Control Reference)
• “How do you handle emergency installs?”
• “Do third parties follow the same approval and change control expectations?”

Typical hangups

• Change tickets exist, but approvals are missing or ambiguous.
• “Authorized software” is implied but not documented anywhere.
• Production is not clearly defined, so teams argue about scope during testing.
• Cloud-native deployments lack a “software installation” record because software ships via images; you still need change evidence tied to image changes.

Frequent implementation mistakes (and how to avoid them)

1. Policy says “management approval,” but no one can show where it happens.
   Fix: enforce an approval field in the change system that requires a manager identity before scheduling.

2. Allowlist exists, but it’s stale or ownerless.
   Fix: assign a control owner and require review as part of operational governance. Tie updates to change control.

3. Engineers have persistent admin access in production.
   Fix: move to just-in-time privileged access with logging; restrict install permissions to controlled roles.

4. “Standard changes” become a loophole for anything.
   Fix: define what qualifies as standard (pre-approved software, known steps, tested rollback). Everything else is normal change.

5. Third-party installs are invisible.
   Fix: require notification and ticket linkage in the contract; sample their changes during periodic reviews.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page avoids case claims. Practically, assessors treat uncontrolled production installs as a high-signal weakness because it correlates with malware exposure, outages, and inability to reproduce or patch systems. HITRUST’s wording also makes this easy to test: auditors can select a production system, list installed software, and ask you to prove each installation was authorized and approved through change control. (HITRUST CSF v11 Control Reference)

A practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Write/refresh the “Operational Software Installation Procedure” for production, including emergency changes and third-party installs. (HITRUST CSF v11 Control Reference)
• Define production scope and system boundaries; publish a production asset list or tagging standard.
• Stand up an initial Authorized Production Software List with owners and a quick approval path.
• Update change request templates to require software name/version, systems impacted, and management approval.

Next 60 days (Enforcement and evidence)

• Reduce production admin rights; implement just-in-time access where available.
• Align CI/CD, image builds, and config management runs to change tickets (ticket ID in commit/build metadata or release notes).
• Begin periodic software inventory checks against the APSL; open remediation tickets for unauthorized items.
• Extend requirements to third parties: evidence request process and contract language updates for renewals.

Next 90 days (Operational maturity)

• Convert frequent installs into well-defined standard changes with pre-approval and clear boundaries.
• Add automated detection for unauthorized software where your endpoint/server controls support it.
• Run an internal mini-audit: pick recent production changes, trace approvals, and validate evidence completeness.
• Formalize exception reporting to leadership (what was installed outside standard, why, and whether it was remediated).

Frequently Asked Questions

What counts as “management approval” for production software installs?

It must be an identifiable approval by a manager or designated authority in your formal change control record, tied to the specific software installation and affected production systems. Email-only approvals are risky unless they are attached to the change record and clearly attributable. (HITRUST CSF v11 Control Reference)

Do container images and CI/CD deployments count as “software installation”?

Yes in practice, because new binaries and packages enter production through image or release changes. Treat image updates, dependency changes, and new agents as production software installs and route them through change control with management approval. (HITRUST CSF v11 Control Reference)

Can we meet this control with policy and tickets, without technical allowlisting?

The requirement is procedural, but audits often test effectiveness. If you cannot show technical guardrails, you need stronger compensating evidence, such as restricted admin access, strong change controls, and periodic reconciliations that detect and remove unauthorized software. (HITRUST CSF v11 Control Reference)

How do we handle emergency installs during an outage?

Define an emergency change path with an on-call manager approver and require retrospective documentation in the change record, including what was installed and why. Keep the logs and post-implementation review notes attached to the ticket. (HITRUST CSF v11 Control Reference)

Our third party manages production infrastructure. Are we still on the hook?

Yes. You need contractual and operational mechanisms that ensure only authorized software is installed and that the third party’s installs follow a formal change control process you can evidence during an assessment. (HITRUST CSF v11 Control Reference)

What evidence is most persuasive to auditors?

A tight chain from change ticket → management approval → deployment evidence/logs → updated inventory showing the installed software matches the approved request. Pair that with an authorized software list and proof that you detect/remediate unauthorized installations. (HITRUST CSF v11 Control Reference)