Managing Changes to Third Party Services

To meet the HITRUST CSF v11 09.g requirement for managing changes to third party services, you must route third-party service changes through a defined change process that (1) considers the criticality of the affected business systems and processes and (2) assesses security impact before the change goes live. The fastest path is to tie third-party change notices to your internal change tickets, require security review for material changes, and retain evidence.

Key takeaways:

• You need a pre-implementation security impact assessment for third-party service changes, not after-the-fact review.
• Critical systems drive rigor: higher criticality means tighter approvals, testing, and rollback requirements.
• Evidence matters as much as process: auditors look for traceable change records tied to security decisions.

“Managing changes to third party services” sounds like a procurement problem, but auditors treat it as an information security control: you are accountable for security outcomes even when the third party operates the service. HITRUST CSF v11 09.g focuses on two operator behaviors: (1) you manage changes to service provision in a structured way, and (2) you assess security impact before implementation, with the level of effort driven by business criticality. ¹

In practice, most failures happen in the seams: the third party updates a subprocessor, changes a hosting region, deprecates a security feature, modifies retention, or introduces a new integration endpoint, and the customer’s security team learns about it after production impact. This requirement is your mandate to close that seam with an operational workflow that connects third-party change notifications to your own change management, risk acceptance, and incident readiness.

This page gives requirement-level implementation guidance you can stand up quickly: who owns what, what “security impact” must cover, how to tier changes by criticality, what artifacts to retain, and the audit questions you should expect.

Regulatory text

HITRUST CSF v11 09.g states: “Changes to the provision of services, including maintaining and improving existing information security policies, procedures, and controls, shall be managed taking into account the criticality of business systems and processes involved. Third-party changes shall be assessed for security impact before implementation.” ¹

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

• You have a repeatable method to receive, evaluate, approve, and track changes that affect third-party services you rely on.
• You classify the impacted business process/system by criticality and scale change rigor accordingly.
• You perform a security impact assessment before the change is implemented (or before you enable/consume the change).
• You retain evidence that the assessment occurred, what was decided, who approved it, and what conditions (testing, rollback, compensating controls) were required. ¹

Plain-English interpretation of the requirement

If a third party changes something about the service you depend on, you must treat that change like a security-relevant change to your own environment. You don’t need to control the third party’s engineering calendar, but you do need a process that:

1. detects the change with enough lead time,
2. determines whether it could affect confidentiality, integrity, or availability,
3. confirms whether your controls and contractual commitments still hold, and
4. documents the decision to accept, mitigate, or reject the change before it takes effect (or before you adopt it). ¹

Who it applies to

Entities: All organizations implementing HITRUST CSF controls. ¹

Operational context (where this shows up):

• SaaS platforms processing regulated or sensitive data (e.g., patient, financial, identity data).
• Cloud hosting providers, managed service providers, and security service providers.
• Third parties supporting critical workflows: claims, revenue cycle, patient engagement, IAM, EDR/SIEM, billing, call centers, payment operations.
• Third-party dependencies inside your products (APIs, SDKs, embedded services, subprocessor chains).

Teams typically involved:

• Third-Party Risk Management (TPRM) or Vendor Management
• Security/GRC
• IT Change Management / Service Management
• Application owners / business process owners
• Procurement and Legal (for notice and approval rights)

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

1) Define “third-party service change” and your intake paths

Create a written definition that includes both technical and non-technical changes that can impact security. Examples:

• Infrastructure: hosting region, data center, cloud account boundaries
• Data: retention, deletion, backup, encryption, key management model
• Access: admin model, SSO/SAML behavior, support access methods
• Subprocessors: additions/removals, role changes
• Security controls: logging, alerting, vulnerability management practices
• Service terms: SLAs, support hours, incident notification procedures

Intake paths to formalize:

• Contractual notices (email addresses, portals)
• Status pages / change calendars
• Release notes / trust center updates
• Direct third-party communications to relationship owners

Output: a one-page “Third-Party Change Intake” SOP and a shared mailbox/queue.

2) Tier third parties and systems by criticality (so rigor is proportional)

HITRUST explicitly requires you to account for criticality. ¹

Create a simple matrix that ties service criticality to change scrutiny:

Criticality tier	Examples	Minimum change requirements
High	Core clinical/financial systems, identity/security tooling, systems with sensitive data	Security impact assessment required; security approval required; rollback/contingency documented; testing/validation evidence retained
Medium	Operational systems with moderate sensitivity	Security review for material changes; owner approval; validation checklist
Low	Non-sensitive, non-critical tools	Record change and confirm no security impact; spot-check periodically

Keep the tiers simple. Auditors want consistency and traceability more than a complex model.

3) Establish a pre-implementation Security Impact Assessment (SIA) workflow

Build an SIA template that can be completed quickly but forces the right questions. Minimum fields:

• Third party name, service, and service owner
• Change description and effective date (or date you plan to enable the change)
• Impacted systems/processes and criticality tier
• Data affected (types, volumes in qualitative terms, flows)
• Control impact analysis:
  • Confidentiality: encryption, access changes, data sharing, subprocessor changes
  • Integrity: data processing logic, validation, audit logs
  • Availability: SLA changes, maintenance windows, architecture changes
• Security requirements impacted: logging, incident notice, monitoring, BCP/DR expectations
• Required mitigations: compensating controls, configuration changes, additional monitoring, contract amendment, user communications, rollback plan
• Decision: approve / approve with conditions / reject / risk accept
• Approvers: service owner + security (and legal/procurement when contractual rights change)

Routing rule: if the change touches sensitive data, authentication/authorization, hosting location, subprocessors, encryption, logging, or incident notification terms, treat it as “material” and require security sign-off.

4) Connect third-party changes to your internal change management tickets

Auditors often fail organizations here: the third party sends release notes, but there is no internal control trail.

Operationalize the linkage:

• Create an internal change ticket for each material third-party change (or a parent ticket for batched releases).
• Attach the SIA and reference the third party’s notice/release note.
• Record required actions (config updates, new monitoring, regression testing, comms).
• Capture completion evidence and post-change validation.

If you use a GRC platform, the control record should reference the ticket ID(s). If you use Daydream, treat it as the system of record for third-party change intake and SIA evidence, then sync key fields to your ITSM ticketing workflow so the audit trail is end-to-end.

5) Make “security impact before implementation” real (timing and gates)

This requirement is explicit: assess before implementation. ¹

Practical gates you can enforce:

• Customer-controlled changes (feature enablement, API version adoption): block enablement until SIA approval is recorded.
• Third-party-controlled changes (their production release): require (a) notice and (b) internal approval of your response plan before the effective date, or document an exception when notice is insufficient.

When you can’t get advance notice, document:

• when you learned of the change,
• what compensating steps you took (heightened monitoring, access review, validation),
• whether you escalated contractually (notice obligations, termination rights, amendment).

6) Update downstream artifacts when the change affects commitments

Changes often cascade. Your process should trigger updates to:

• Data flow diagrams (if data movement changes)
• Subprocessor registers (if subprocessors change)
• Security requirements in contracts/SOWs (if terms change)
• Customer commitments (if you are also a third party to others)

7) Verify after the change (close the loop)

HITRUST 09.g is about managing change, so close-out matters:

• Validate expected controls (logging present, encryption unchanged, access paths correct).
• Capture evidence (screenshots, configuration exports, test results).
• Record any incidents/degradations and lessons learned for future gating.

Required evidence and artifacts to retain

Auditors will ask for proof that the process runs, not just a policy. Keep:

• Third-Party Change Management policy/SOP referencing criticality and SIA-before-implementation ¹
• Inventory of third parties and criticality tiering (service-to-system mapping)
• Change intake records (emails, portal notices, release notes) tied to internal records
• Security Impact Assessments (completed templates with approvers and dates)
• Internal change tickets with links to SIA and implementation tasks
• Approval evidence (security approval, risk acceptance, or rejection rationale)
• Validation artifacts (test results, monitoring confirmation, config evidence)
• Exceptions (late notice, emergency changes) with compensating controls and follow-up actions

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “Show me the last few third-party service changes and your pre-implementation security assessment.” If you can’t produce examples quickly, the control fails operationally.
2. “How do you determine criticality, and how does it change your process?” They will test consistency across teams.
3. “What counts as a security-impacting change?” Auditors dislike vague definitions.
4. “How do you know you heard about changes?” They will look for intake mechanisms, not informal forwarding.
5. “How do you handle changes that happen without notice?” They will accept exceptions only if documented with risk handling.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating release notes as “reviewed” without a recorded security decision.
  Fix: require an SIA (even short-form) for material changes, attached to a ticket with approvers.

• Mistake: Only applying change management to “critical vendors,” ignoring critical systems.
  Fix: map third-party services to business processes/systems; let criticality drive rigor, as HITRUST requires. ¹

• Mistake: No contract hooks for notice.
  Fix: add change notification clauses, subprocessor notice, and security-impact change notice to templates; route notices to a monitored queue.

• Mistake: Security is informed after implementation.
  Fix: implement gating for customer-controlled changes and a documented pre-effective-date review for third-party-controlled changes.

• Mistake: “Security impact assessment” means only privacy.
  Fix: cover CIA (confidentiality, integrity, availability) plus logging, access paths, and incident readiness.

Risk implications (why operators care)

Unmanaged third-party changes create blind spots that break your control environment: encryption posture can change, logs can disappear, subprocessors can expand your attack surface, and availability assumptions can fail. HITRUST 09.g forces a discipline that reduces “surprise” changes and creates a defensible record of risk decisions. ¹

Practical execution plan (30/60/90)

Use a phased approach with clear deliverables. Adjust pacing to your environment and staffing.

First 30 days (stand up the minimum viable process)

• Publish a one-page SOP: what constitutes a third-party service change, where notices go, and when security review is required.
• Set up intake: shared mailbox/queue, ownership, backup coverage.
• Create SIA templates (full and short-form) and approval routing.
• Pick a small set of high-criticality third-party services and pilot the workflow end-to-end with real changes.

By 60 days (make it repeatable and auditable)

• Complete criticality tiering for third-party services supporting critical systems/processes.
• Integrate with ITSM: create ticket types, required fields, and “no approval, no enablement” gates for customer-controlled changes.
• Update contract templates for change notice and subprocessor notice, and begin retrofitting renewals.

By 90 days (scale and harden)

• Expand coverage to medium-criticality third parties.
• Add periodic reconciliation: compare third-party release notes/portals against your internal ticket log to confirm intake is working.
• Formalize exception handling for late/no-notice changes.
• Train service owners and procurement on what triggers an SIA and how to route changes.

Daydream can reduce friction by centralizing third-party inventories, notice intake, and SIA evidence, then pushing the resulting tasks into your existing change system so you keep one audit trail across security, IT, and procurement.

Frequently Asked Questions

Do we need to assess every third-party release note?

No. You need a defined method to identify which changes are security-impacting, then assess those before implementation or before you enable them. Record your triage decision so you can show why a change did not require an SIA. ¹

What if the third party deploys changes without advance notice?

Document the exception: when you learned of it, the security impact review performed as soon as practicable, and compensating controls (extra monitoring, access review, validation). Then address the root cause through contract terms and escalation paths. ¹

What counts as “before implementation” if we can’t control the third party’s production schedule?

For third-party-controlled releases, “before implementation” should mean before the effective date (based on notice) or before your organization adopts/enables the changed capability. If you receive notice late, treat it as an exception and record the risk decision. ¹

Who should approve the security impact assessment?

At minimum, the service owner and an authorized security reviewer should approve material changes; add legal/procurement when contractual commitments or subprocessors change. Use a RACI so approvals do not stall. ¹

How do we tie criticality to the required rigor without overengineering?

Use a small number of tiers and define the minimum required steps per tier (SIA depth, approval level, validation requirements, rollback expectations). Consistency beats complexity in audits. ¹

What evidence is most commonly missing during audits?

A traceable chain from third-party notice → internal ticket → pre-implementation security decision → validation/close-out. Keep all four components linked and timestamped. ¹

Footnotes

1. HITRUST CSF v11 Control Reference