Critical Infrastructure & Dependencies
Version: 2.2.1

This policy defines Thriveworks governance framework for identifying, classifying, and protecting the digital infrastructure and third-party services essential to business operations, cybersecurity, and regulatory compliance. By integrating tiered risk modeling, real-time monitoring, and resilience engineering, the policy ensures that mission-critical systems remain available, secure, and aligned with standards such as HIPAA, HITRUST, and the NIST Cybersecurity Framework (CSF) 2.0.

Created:

by Ben Bone

Current Effective Approval:
05/03/2025

Logical Domain Strategy:

View more

Policy Summary

Thriveworks' Critical Infrastructure & Dependencies Policy establishes the organizational framework for identifying, managing, and protecting digital systems and services essential to business continuity, cybersecurity, and patient care. This policy, a core element of our enterprise risk management strategy, ensures all mission-critical platforms, dependencies, and third-party services remain resilient, observable, and aligned with compliance standards—including HIPAA, HITRUST, and NIST Cybersecurity Framework (CSF) 2.0.
The policy governs the complete lifecycle of infrastructure dependency management, from discovery and classification through monitoring, resilience planning, and incident response. It provides formal oversight of cloud platforms, authentication systems, electronic health records (EHRs), network infrastructure, and data pipelines, while enforcing controls against Shadow IT and unauthorized technologies.
Using a tiered risk model, Thriveworks classifies infrastructure to prioritize security and continuity measures based on system criticality. Tier 1 systems—including identity providers and security telemetry pipelines—undergo real-time monitoring, geo-redundant failover, and strict access controls. We monitor these dependencies through platforms like Datadog, Tanium, and SentinelOne, with additional visibility from Freshservice, CloudCraft, and SumoLogic.
We maintain centralized documentation of infrastructure relationships, recovery objectives (RTO/RPO), and vendor service levels to enable precise responses to outages and security events. Regular incident playbooks, tabletop exercises, and quarterly dependency reviews keep critical systems aligned with business and regulatory expectations.
When critical events occur, they trigger structured escalation and automated containment protocols. Post-incident reviews validate dependency classifications and operational readiness. Our policy requires encrypted backups, identity-federated access control, complete telemetry coverage, and continuous failover testing to maintain resilience across environments.
Through proactive management of cyber dependencies and critical systems, Thriveworks reduces cascading risk, protects ePHI, and ensures secure delivery of digital health services. This policy serves as an evolving control system, strengthened through automation, audit readiness, and integration with our broader business continuity and disaster recovery strategies.

Critical Infrastructure & Dependencies

2

v2.2.1

Introduction
This Critical Infrastructure & Dependencies Policy establishes the principles and governance for identifying, documenting, and managing critical cyber infrastructure that supports Thriveworks' operations. It outlines key systems, services, and technology dependencies essential for delivering secure and reliable services, while providing a framework to ensure these dependencies remain resilient, monitored, and compliant with regulatory standards.
The policy guides all personnel within Thriveworks—including staff, contractors, and technology partners—in understanding and managing critical infrastructure dependencies. This encompasses infrastructure platforms, cloud services, authentication layers, data pipelines, monitoring tools, and third-party service providers.
Following the NIST Cybersecurity Framework (CSF) and HIPAA requirements, this policy helps Thriveworks mitigate operational and cybersecurity risks. It protects the confidentiality, integrity, and availability of electronic protected health information (ePHI), maintains compliance, and strengthens digital resilience and operational continuity.
The procedures defined in this policy are essential for:
Ensuring consistent availability and integrity of mission-critical services.
Managing cascading risks from dependent systems.
Supporting incident response, business continuity, and disaster recovery planning.
Meeting compliance requirements and audit readiness for HIPAA and NIST CSF.

Through robust documentation, regular assessments, and structured governance, Thriveworks protects all critical cyber infrastructure and dependencies from disruption, misconfiguration, and malicious activity.

Critical Infrastructure & Dependencies

3

v2.2.1

Scope
This policy applies to all Thriveworks personnel—including employees, contractors, and authorized third-party service providers—who interact with or manage the organization's cyber infrastructure and dependencies. It covers the systems, services, platforms, and technologies that support Thriveworks' digital operations, focusing on components essential for cybersecurity, operational continuity, and regulatory compliance.
The scope of this policy includes:
Cloud Infrastructure
Public, private, and hybrid cloud environments, including compute, storage, network, and identity services provided by platforms such as AWS, GCP, Azure, and Heroku.
Core Systems & Platforms
Critical systems such as authentication services, identity management, electronic health record (EHR) systems, endpoint security platforms, and zero trust access layers.
3rd-Party Dependencies
SaaS platforms, APIs, security tooling, and managed services that directly impact Thriveworks' security posture or business delivery.
Monitoring & Telemetry
Platforms that collect, analyze, and alert on system behavior, including SIEM, EDR, CSPM, vulnerability scanners, and observability tools.
Network Infrastructure
Core networking elements including VPNs, DNS services, CDNs, and secure communication protocols.
Data Pipelines
Systems and integrations that handle secure transport and processing of sensitive information.
Shadow IT
Unauthorized software, hardware, cloud services, or applications used without IT or Security team approval. This introduces unmanaged risk and is prohibited under this policy.
This policy applies to all Thriveworks environments—production, staging, development, and disaster recovery. It is technology-agnostic and adaptable as Thriveworks evolves its technical architecture or adopts new services.
The policy excludes physical infrastructure and facilities, except for assets that directly support digital infrastructure (e.g., on-premises servers or security appliances).

Critical Infrastructure & Dependencies

4

v2.2.1

Definitions
This section establishes a common vocabulary for terms used throughout the Critical Infrastructure & Dependencies Policy to ensure consistency and clarity across the Thriveworks organization.
Critical Infrastructure
Digital systems, platforms, or services that are essential to the functioning, security, or regulatory compliance of Thriveworks. Disruption to these components would have a significant impact on operations, service availability, or data protection.
Dependency
Any internal or external service, system, component, or provider that a critical infrastructure element relies upon to function correctly. Dependencies can be technical (e.g., APIs, DNS), operational (e.g., cloud platforms), or human (e.g., vendors).
Mission-Critical Systems
Infrastructure or services whose failure would immediately impair the ability to provide core services (e.g., EHR, identity providers, SIEMs).
Third-party Services
External vendors or platforms used by Thriveworks to host, process, transmit, or protect data. These include SaaS providers, cloud platforms, MSSPs, and infrastructure-as-a-service offerings.
Single Point of Failure (SPOF)
A system or component that, if it fails, will stop the entire service from working. SPOFs are identified and addressed as part of infrastructure risk assessments.
Cyber Dependency
A reliance on any digital technology that, if compromised or unavailable, would affect the confidentiality, integrity, or availability of Thriveworks' information systems.
Shadow IT
Hardware, software, or services that are used within the organization without explicit approval from IT or Security. These tools pose unmanaged risk and fall outside official controls, logging, and policy compliance.
Resilience
The ability of Thriveworks' systems to continue operating under adverse conditions, including outages, cyberattacks, or infrastructure failure. Resilience is achieved through redundancy, failover planning, and proactive monitoring.
Availability Zone (AZ)
A distinct geographic location within a cloud provider's infrastructure used to enhance system redundancy and fault tolerance. Thriveworks may use multiple AZs to ensure high availability
Security Posture
The overall strength and readiness of Thriveworks' infrastructure to detect, resist, and respond to cyber threats. It includes configurations, controls, monitoring, and staff awareness.
Mean Time to Recover / Respond / Resolve (MTTR)
A metric used to measure the average time taken to detect, respond to, and fully recover from a system failure or security incident. MTTR is used to assess the performance of Thriveworks' incident response and remediation capabilities. Lower MTTR indicates faster containment and recovery.
Key Risk Indicator (KRI)
A measurable value used to signal the increasing risk exposure within specific areas of operations or security. KRIs are used to proactively identify threats or vulnerabilities before they result in incidents. Examples include the number of unpatched systems, failed backups, or unauthorized access attempts.

Critical Infrastructure & Dependencies

5

v2.2.1

Infrastructure Tiering Model
Tier 1: Mission-Critical Systems
Systems whose disruption would have an immediate and severe impact on business operations, patient care, or data protection. (e.g., EHR, identity providers, security infrastructure)
Tier 2: Essential Systems
Systems necessary for operations, but where short-term outages are tolerable. (e.g., CRM, IT ticketing, file sharing)
Tier 3: Support Systems
Internal tools or platforms that support productivity but do not directly impact patient care or compliance. (e.g., dashboards, documentation systems)
Tier 4: Non-Critical Systems
Tools or environments used for discretionary or low-priority tasks. (e.g., development sandboxes, testing environments)

This tiering framework is used to prioritize monitoring, incident response, business continuity planning, and vendor due diligence activities.
Infrastructure Resource - Tagging Strategy

REQUIRED Tags for HIPAA resources

Critical Infrastructure & Dependencies

6

v2.2.1

Identification of Critical Infrastructure & Dependencies
Thriveworks maintains a structured, repeatable process for identifying critical cyber infrastructure components and their dependencies. This process ensures operational continuity, reduces risk, and maintains regulatory alignment while supporting proactive resilience planning, effective risk treatment, and cybersecurity control prioritization.
Identification Criteria
Critical infrastructure and dependencies are identified through several key lenses. From a business perspective, we evaluate systems that could disrupt healthcare services, patient data access, or regulatory obligations, such as EHR and IAM systems. Security considerations focus on components affecting confidentiality, integrity, and availability, including identity providers and network gateways. We also assess operational dependencies like DNS and authentication layers, as well as compliance requirements for HIPAA-protected workflows and breach detection mechanisms. Special attention is given to potential Single Points of Failure (SPOFs) and systems lacking proper redundancy.
Discovery and Assessment
Our identification process combines multiple approaches, including Business Impact Analyses, security risk assessments, and close collaboration with department leads. We regularly conduct inventory audits of cloud assets and third-party tools, while mapping dependencies during vendor onboarding and project planning. This process is supported by key tools like Freshservice CMDB for asset tracking, Datadog and CloudCraft for infrastructure visualization, and detailed logical diagrams showing cross-service relationships.
Documentation Standards
All infrastructure and dependencies are recorded in a centralized repository, capturing essential details such as system classification, primary functions, dependencies, hosting information, and security requirements. This documentation extends to our external dependencies, which include critical platforms such as:
AWS
Heroku
Cloudflare
Mailgun
Retool
Fivetran
Rudderstack
Vercel
Github
These platforms are integral to our production workflows and undergo rigorous monitoring and compliance reviews.
Continuous Review
We conduct quarterly reviews of dependency data, with additional assessments during major changes such as platform adoptions or architectural updates. Unscheduled reviews are triggered by security incidents, operational failures, or regulatory changes that affect our infrastructure definitions.

Critical Infrastructure & Dependencies

7

v2.2.1

Dependency Classification
To effectively manage risk and operational resilience, Thriveworks classifies infrastructure dependencies based on their criticality to business operations, security posture, and regulatory compliance. This classification guides prioritized monitoring, incident response planning, business continuity, and resource allocation.
Tier Classification Model
Dependencies are categorized into four tiers.
Tier 1 comprises mission-critical dependencies that directly affect patient care, compliance, or real-time operations. These dependencies—including identity management platforms, EHR systems, VPNs, and SIEM/EDR tools—require zero downtime and must maintain high availability with failover capability.
Tier 2 encompasses essential dependencies that significantly impact business operations, though not immediately affecting life-critical functions. These systems can handle brief interruptions of up to a few hours. Examples include file sharing services, customer engagement tools, and analytics dashboards supporting near-real-time insights.
Tier 3 consists of supportive dependencies that facilitate internal workflows, reporting, and productivity. These systems—such as documentation platforms, HRIS tools, and non-production collaboration services—can withstand downtime up to one business day.
Tier 4 comprises non-critical dependencies. These discretionary tools or services present minimal operational risk when unavailable, including development sandboxes, legacy systems, and beta features. Extended or indefinite downtime is acceptable for Tier 4 systems.
Classification Criteria
Classification decisions stem from business impact analyses (BIAs), regulatory requirements—especially regarding HIPAA and ePHI—system integration depth, and operational necessity. Recovery expectations such as RTO/RPO and vendor SLA commitments also factor into the assessment.
Ownership and Maintenance
System owners propose classification levels during onboarding or major system changes. IT Security reviews and validates these classifications to ensure alignment with organizational risk tolerance. The CMDB and CloudCraft diagrams use tier-based tagging for clear visibility and filtering.
Review and Reclassification
Classifications undergo quarterly reviews alongside infrastructure risk audits. Additional reviews occur after significant events like system upgrades, vendor changes, or post-incident analyses. When outages reveal misclassified dependencies or cascade failures, classifications receive immediate reassessment. The system owner, security team, and infrastructure team coordinate reclassifications, updating all documentation, diagrams, and monitoring dashboards accordingly.

This tiered model enables Thriveworks to manage its infrastructure landscape with precision and adaptability, ensuring critical systems receive appropriate attention and protection.

Critical Infrastructure & Dependencies

8

v2.2.1

Control Requirements
To ensure the availability, integrity, and security of Thriveworks' critical infrastructure and dependencies, this section outlines baseline control requirements for implementation across the ecosystem. These controls mitigate operational disruptions, reduce cybersecurity risk, and maintain compliance with HIPAA and the NIST Cybersecurity Framework.

ALL Tier 1 & Tier 2 Dependencies MUST:
Incorporate resilience and failover capabilities. This includes redundant hosting, load balancing, multi-region availability zones, and automated recovery where feasible. Mission-critical systems require continuous monitoring with alerting thresholds for health, availability, and security posture. This monitoring must span the entire stack—from infrastructure and network layers to applications and integrations.
Access to critical systems and administrative interfaces requires strict control through identity federation, strong authentication, and role-based access control. Implement just-in-time provisioning and time-bound access for elevated privileges. All system changes must follow documented change control procedures, including approval workflows and impact assessments before deployment.
For operational continuity, critical infrastructure requires formal backup and recovery strategies. Backups must be encrypted, regularly validated, and stored in geographically separate locations. Systems handling protected health information (PHI) need additional safeguards, including encryption for data at rest and in transit, minimum necessary access, and audit logging.
Third-party dependencies—including SaaS tools, APIs, and infrastructure providers—require risk evaluation before onboarding and periodic review thereafter. These evaluations must consider service-level commitments, breach response capabilities, incident communication plans, and regulatory compliance.
All systems must connect to Thriveworks' centralized logging, monitoring, and telemetry platforms. This enables proactive detection of anomalies, unauthorized access, and performance issues. Systems failing to meet telemetry or recovery requirements cannot operate in production or patient-facing environments.
These requirements will evolve based on incident lessons, audit findings, threat intelligence, and regulatory changes. The IT Security and Infrastructure teams, working with system owners, must ensure consistent implementation and ongoing improvement of these controls.

Critical Infrastructure & Dependencies

9

v2.2.1

Monitoring and Logging of Dependencies
Maintaining visibility into the performance, availability, and security of critical infrastructure is essential for proactive risk management. At Thriveworks, monitoring and logging aren't passive observability measures—they form an active line of defense against operational and cybersecurity threats.
All mission-critical and essential systems must have real-time telemetry that provides actionable insights into system behavior, including performance metrics, error tracking, access events, and integration health. This monitoring spans infrastructure layers, applications, APIs, and third-party services involved in core workflows.
Systems must aggregate their logs into a centralized platform. These logs need sufficient detail for forensic investigations, compliance audits, and ongoing security analysis. The system must record and preserve access logs, configuration changes, authentication attempts, and data movement events according to HIPAA and internal data governance retention policies.
System anomalies must trigger automated alerts through established escalation workflows. We track Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) to evaluate monitoring effectiveness and organizational responsiveness. Alert thresholds undergo periodic review to match current risk levels and operational patterns, with ongoing tuning to reduce false positives.
While monitoring responsibilities span Security Operations, Infrastructure Engineering, and System Owners, all logs and telemetry feed into a unified platform for correlation, visualization, and auditability. Third-party monitoring agents and managed SOC services must follow standardized protocols for onboarding and verification to ensure complete coverage.
Logging and monitoring configurations require ongoing maintenance, as they can drift or develop gaps over time. Thriveworks validates monitoring pipelines and logging completeness through regular internal audits and tabletop scenarios.

This comprehensive approach ensures not just environmental visibility, but enables swift, intelligent responses to emerging threats and operational anomalies.

Critical Infrastructure & Dependencies

10

v2.2.1

Data Classification Mapping
To ensure that infrastructure controls are proportionate to the sensitivity of the data processed by each system, Thriveworks applies a formal mapping between data classifications and corresponding control requirements. This mapping is designed to meet regulatory obligations under HIPAA and other frameworks, while enforcing a consistent approach to risk-based infrastructure governance.
Classification Levels
Thriveworks categorizes data into the following classes:
PHI (Protected Health Information)
Regulated under HIPAA; includes patient records, diagnostics, clinical metadata.
PII (Personally Identifiable Information)
Names, email addresses, phone numbers, employee records.
Restricted
Sensitive internal data such as credentials, system diagrams, or source code.
Confidential
Business plans, non-public financials, internal documentation.
Public
Marketing content, public website data, anonymized metrics.
Control Mapping Matrix
Note: These classifications are enforced using mandatory metadata tags on all infrastructure resources (e.g., DataClass, Boundary, Backup, RetentionPolicy). Systems missing required tags or controls cannot be promoted to production environments.
Classification Assignment
System owners are responsible for assigning initial data classification during onboarding or major architectural changes. IT Security validates classification against intended use cases and verifies enforcement of relevant controls.
Oversight and Review
The Compliance and Security teams review data classification mappings as part of quarterly infrastructure audits. Systems that undergo role changes, data schema updates, or integrations with new services are flagged for reclassification.

Critical Infrastructure & Dependencies

11

v2.2.1

Incident Response and Resilience Planning
Thriveworks integrates incident response and infrastructure resilience into a unified strategy to rapidly contain, recover from, and learn from disruptive events affecting critical systems and dependencies.
When monitoring alerts or user reports detect a system anomaly, failure, or suspected compromise, response teams initiate pre-defined escalation protocols. These protocols ensure swift notification of appropriate personnel based on severity and immediate containment actions. Containment may include isolating affected services, disabling access, or rerouting traffic to redundant infrastructure.
Each critical system maps to an incident playbook detailing specific response steps, roles, and communication responsibilities. Teams validate these playbooks through simulation exercises—including tabletop drills and red team assessments—and update them based on architectural changes and lessons learned.
Resilience planning extends beyond disaster recovery documentation—it's woven into infrastructure design and operations. Mission-critical services must have documented and tested failover paths, with regular simulated failure testing. Each Tier 1 and Tier 2 system requires established Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs), along with monitoring to track performance against these targets.
To support these efforts, Thriveworks maintains a centralized record of critical dependencies and their recovery characteristics, including hosting regions, data replication strategies, backup coverage, and recovery procedures. The Infrastructure, Security, and Risk Management teams jointly maintain these records.
After each incident, the organization conducts a thorough retrospective examining root causes, resolution timelines, and potential gaps in dependency classification, monitoring, or documentation. Teams track follow-up actions to completion, with significant findings potentially triggering policy or architectural changes.
By combining incident response with resilience engineering, Thriveworks ensures recovery is a planned, tested capability across all critical services—not just a reactive measure. This approach reinforces the organization's commitment to security, continuity, and trust.

Critical Infrastructure & Dependencies

12

v2.2.1

Audit Readiness
NIST CSF Control Mapping - Critical Infrastructure & Dependencies Policy
This section documents the formal mapping between Thriveworks’ Critical Infrastructure & Dependencies Policy and the NIST Cybersecurity Framework (CSF) version 2.0. It serves as a compliance reference that demonstrates how Thriveworks' infrastructure governance and dependency management practices align with NIST’s cybersecurity functions and subcategories.
Purpose of this matrix: The primary objective of this matrix is to support internal and external audits, enable regulatory readiness, and demonstrate that Thriveworks’ dependency management practices satisfy requirements outlined in HIPAA, HITRUST, and the NIST CSF. By linking operational, architectural, and security practices to specific CSF subcategories, Thriveworks reinforces its evidence base for compliance, risk mitigation, and continuity assurance.
Why this matters: As healthcare delivery increasingly depends on cloud infrastructure, third-party SaaS platforms, and interconnected digital services, robust dependency management becomes essential. Mapping this policy to NIST CSF 2.0 provides measurable assurance that Thriveworks' critical infrastructure is resilient, observable, and governed by policy-aligned controls. It also facilitates gap identification and continuous improvement across system monitoring, incident recovery, and risk oversight.

Critical Infrastructure & Dependencies

13

v2.2.1

Audit Readiness
Auditor-Facing SOP (Artifact Collection)

This SOP provides control operators and third-party auditors with step-by-step documentation to verify the operational enforcement of Thriveworks' Zero Trust Network Architecture (ZTNA) controls. It maps specific security capabilities to NIST CSF 2.0 subcategories and presents evidence in the form of screenshots, logs, config snapshots, and process workflows.
The scope of this SOP covers identity enforcement, posture validation, network segmentation, session monitoring, incident response, and configuration governance across the compliance boundary defined — Thriveworks ZTNA infrastructure.
System Walkthrough (With Evidence)
1
Access Control (PR.AC-P1, PR.AC-P2)
Verify: MFA and SSO enforcement via Google Workspace
  • Screenshot of MFA config in Google Admin
  • Screenshot of login logs in Google Workspace Security Center
  • RBAC group memberships from Workday mapped to Perimeter 81
2
Device Posture (PR.PT-P3, DE.CM-P3)
Verify: Active SentinelOne agent, disk encryption, OS patch level
  • Screenshot of posture policy in Harmony
  • Sample failed posture log in SumoLogic (timestamp + device ID)
3
ZTNA Segmentation (PR.PT-P1, DE.CM-P4)
Verify: IPSec tunnel config, gateway failover, app segmentation
  • Screenshot of gateway settings and tunnel CIDRs
  • SumoLogic log of a gateway switch during a DR test
  • Published applications list tied to roles
4
Monitoring and Detection (DE.CM-P1, DE.CM-P6, RS.AN-P1)
Verify: Alerts for ZTNA anomalies and SOC workflows
  • Example Freshservice ticket created from a failed policy
  • SumoLogic alert rule definition
  • Datadog dashboard showing endpoint health
5
Resilience & Recovery (RC.RP-P1, RC.IM-P1)
Verify:
Tunnel failover, config restore, DR validation
  • DR test results with latency metrics
  • Config diff showing rollback/recovery
  • Meeting notes from DR test post-mortem
6
Change Management (PR.MA-P1)
  • Screenshots of CMDB entries tied to ZTNA assets
  • Example CAB approval for tunnel modification
  • Audit trail from Freshservice with timestamps and approvals
7
Log Retention
  • Diagram or screenshot of your 7-year log retention policy in SumoLogic/Glacier
  • Config sample showing AWS lifecycle policy
  • Sample retrieval of archived logs for an incident
8
Version Control & Review
  • SOP and policy are reviewed annually or after major infra changes
  • Reviewed by: Security Engineering, Compliance, Cloud Ops
  • Store versions in your documentation repo with changelog (date, change owner, summary)

Critical Infrastructure & Dependencies

14

v2.2.1

Policy Review & Approval
This Critical Infrastructure & Dependencies Policy is a living document and shall be reviewed at least annually, or upon any significant change to Thriveworks technology stack, organizational structure, or applicable regulatory landscape. Additional reviews may also be initiated following disaster recovery tests, incident investigations, or business continuity planning updates.
All changes to this policy require executive leadership approval. The final, approved version will be distributed to all relevant personnel and made available through Thriveworks central documentation repository. Compliance with the latest version of this policy is mandatory for all affected teams.
Ben Bone
Vice President, Technology

Policy Responsibilities:
Leads the configuration policy review cycle and cross-functional coordination. The VP is responsible for collecting input from Compliance, Security, IT Operations, and DevOps teams to ensure policy updates are technically accurate, operationally practical, and aligned with Thriveworks’ risk management and compliance objectives. Proposed changes are consolidated and prepared for executive review and final approval.
Marc Brooks
Chief Admin Officer & General Counsel

Policy Responsibilities:
Serves as the executive sponsor of the Critical Infrastructure & Dependencies Policy, providing final approval authority. The CAO is responsible for ensuring that the policy aligns with Thriveworks’ broader organizational objectives, regulatory commitments, and strategic risk tolerance. This includes reviewing proposed updates, validating that appropriate stakeholder collaboration has occurred, and formally endorsing the policy before publication or reissuance.

Critical Infrastructure & Dependencies

15

v2.2.1