The purpose of this Zero Trust Network Access (ZTNA) Policy is to define the security architecture, control objectives, and operational enforcement mechanisms used by Thriveworks to govern access to corporate systems, clinical applications, and protected health information (PHI) across a distributed cloud infrastructure. Thriveworks operates a complex hybrid environment that includes containerized workloads in Amazon Elastic Kubernetes Service (EKS), persistent SQL databases hosted on Amazon EC2, HIPAA-aligned applications deployed in Heroku Shield Private Spaces, and SFTP integrations with external payers and partners. Ensuring that access to these systems is explicitly authorized, contextually evaluated, and continuously monitored is a foundational requirement for regulatory compliance and business continuity.

Unlike traditional perimeter-based security models that rely on static IP whitelisting and VPN concentrators, Thriveworks implements a modern Zero Trust security posture, which assumes breach and requires dynamic authentication, continuous device validation, and segmented application-level access enforcement. This policy governs how that posture is operationalized using Perimeter 81 as the ZTNA platform, with secure connectivity extended through a combination of browser-based access, Always-On VPN clients, and site-to-site IPSec tunnels. These tunnels connect Thriveworks' ZTNA mesh to backend services in AWS Virtual Private Clouds (VPCs) and allow for direct access to backend database clusters, microservice APIs, and application orchestration layers that are otherwise isolated from the public internet.

Access decisions are rooted in identity, posture, and session context. Google Workspace serves as the central identity provider and SAML/OIDC authority, integrating directly with Perimeter 81 to enforce Single Sign-On (SSO) and Multi-Factor Authentication (MFA) for all users. Endpoint compliance is validated using Perimeter 81's device posture enforcement engine, ensuring that only corporate-managed systems with active EDR agents, disk encryption, and updated antivirus definitions are allowed to establish secure sessions. Web-based traffic is routed through geographically distributed Secure Web Gateway (SWG) nodes, where domain filtering, TLS inspection, and DLP controls are applied before allowing outbound requests to reach the open internet.

All access activity—whether to internal applications, backend AWS services, or external web resources—is centrally logged to SumoLogic, where it is correlated with device metadata, user identity, and session behavior. These events are continuously monitored by eSentire, Thriveworks' managed Security Operations Center (SOC), which provides 24/7 threat detection, enrichment, and incident response in coordination with internal security engineering staff.

ZTNA at Thriveworks is designed to eliminate implicit trust in the network and instead validate every access request dynamically. User and device access is granted only when multiple contextual signals—such as identity, endpoint posture, network location, and risk score—meet predefined policy criteria. Key pillars of our implementation include:

All users authenticating through Harmony SASE are subject to enforced Single Sign-On (SSO) using Google credentials and Multi-Factor Authentication (MFA) using either hardware-based security keys (YubiKey) for IT administrators or app-based authenticators for everyone else. SSO is enforced not only at the login stage but also at the point of application access, gateway registration, and policy approval workflows.

Access entitlements are assigned using Role-Based Access Control (RBAC), with user roles derived directly from Workday HRIS attributes and synchronized to Google Workspace organizational units (OUs) and groups. These groups are mapped into Harmony SASE Member Access Groups, which control:

Privileged access is tightly governed under separate administrative roles, which include additional session verification policies. Admin actions such as network configuration changes, tunnel modifications, and application publishing are logged and reviewed on a biweekly basis. Just-In-Time access may be granted through manual overrides for emergency operations, but must be documented and expire within 24 hours unless renewed.

To maintain integrity and compliance, quarterly access reviews are conducted across all Access Groups, in coordination with department heads and security auditors. These reviews validate:

All access data is logged to SumoLogic, correlated with endpoint identity and IP metadata, and monitored by eSentire SOC for anomalous patterns, privilege escalation attempts, or policy violations.

This section governs how Thriveworks establishes and enforces the principle of least privilege, using verified identity, system-integrated role data, and continuous session monitoring to limit access to what is necessary.

Thriveworks enforces device trust through continuous posture assessment and agent-based compliance validation as a prerequisite for all Zero Trust Network Access. This strategy ensures that only verified and healthy endpoints—meeting security baselines and running corporate-approved configurations—can access internal networks, applications, or internet gateways via Perimeter 81.

Posture validation begins prior to tunnel initiation or application access. Harmony's native posture engine runs checks at two critical intervals: upon connection attempt, and every 20 minutes thereafter while the session is active. These posture assessments are enforced for both Windows and macOS platforms, and they apply to users connecting via Always-On VPN or browser-based session proxies.

All posture check failures result in access denial until remediated. The posture engine provides client-side remediation prompts and communicates health state directly to the Perimeter 81 policy engine. Devices failing posture checks are logged with endpoint ID, OS version, user identity, and failure reason.

All posture policy configurations are version-controlled and reviewed quarterly by Systems & Security Engineering. Any changes to enforcement logic, threshold values, or supported platforms must be:

Posture failures and remediation activity are logged centrally in SumoLogic and retained for a minimum of seven years in accordance with HIPAA and Thriveworks data retention policy.

Thriveworks implements a multi-layered network architecture purpose-built to support a Zero Trust security model across hybrid and multi-cloud environments. This architecture is anchored by Harmony SASE’s gateway-based mesh overlay, which interconnects users, services, and infrastructure through encrypted tunnels and strict access segmentation. The environment spans cloud-native assets in AWS and Heroku, remote workforce endpoints, and backend services segmented by risk domain, business unit, and geography.

Thriveworks ensures that the Zero Trust Network Access (ZTNA) environment is resilient against regional disruptions, infrastructure failures, and system degradations. Recovery operations are governed by the following principles:

Thriveworks employs a multi-tiered security telemetry and monitoring strategy that aligns with Zero Trust principles and supports real-time visibility into user behavior, endpoint health, and network activity. Logging is not a passive archival mechanism, but an active enforcement layer tied to behavioral anomaly detection, automated alerting, and incident response. Telemetry is collected from every critical layer of the infrastructure stack—including endpoints, network gateways, cloud services, applications, and identity systems—and is centralized in a unified analytics platform to support correlation and threat detection.

Thriveworks collects structured and unstructured logs & event data from the following sources:

Before analysis, logs are enriched with context to support actionable insights and reduce false positives. Enrichment layers include:

Monitoring pipelines are defined and maintained in Datadog and SumoLogic. Detection rules are designed around known attack patterns, behavior-based anomalies, and policy violations. Key categories include:

All audit and system logs are retained and searchable for a minimum of 7 years, with a tiered architecture:

Readiness policy include:

The change management framework is implemented in Freshservice, where all ZTNA-related assets are tracked through a fully populated Configuration Management Database (CMDB). Assets include gateways, IPSec tunnels, DNS override entries, firewall policies, access groups, application profiles, and posture enforcement templates. Each asset is manually registered and linked to:

Once the CR has passed its initial technical and dependency reviews, it is submitted to the Change Advisory Board (CAB) for evaluation. The CAB is a multi-disciplinary governance team responsible for:

CAB approval is required before any changes are applied in production environments. The CAB approval log is digitally signed and timestamped in Freshservice for audit retention. Urgent changes (e.g., those involving an active security incident) may be fast-tracked via an emergency change process but must be post-validated by CAB within 48 hours of implementation.

After CAB approval, the administrator executes the change in accordance with documented procedures. Every step must be tracked in the Freshservice CR timeline, including:

All CRs are version-controlled and tagged by environment (e.g., staging, production, clinical) with immutable timestamps. The Freshservice CMDB maintains a complete audit history for each asset, including:

Change metrics such as Mean Time to Approve (MTTA), Mean Time to Deploy (MTTD), and Mean Time to Detect Reversion (MTTRv) are calculated monthly. These are reviewed during Quarterly Security and Operations Governance meetings to identify process bottlenecks and improve cross-team efficiency.

All change-related data—logs, evidence attachments, audit trails—are retained in S3 and Glacier with a 7-year lifecycle per HIPAA and NIST CSF policy alignment.

This section documents the formal mapping between Thriveworks’ Zero Trust Network Architecture (ZTNA) Policy and the NIST Cybersecurity Framework (CSF) version 2.0. It serves as a compliance reference that demonstrates how ZTNA-related controls align with key cybersecurity functions and subcategories defined by NIST.

Purpose of this matrix: The primary objective of this matrix is to support internal and external audits, enable regulatory readiness, and ensure that Thriveworks can clearly show how its Zero Trust strategy satisfies the requirements of industry-standard frameworks such as HIPAA, HITRUST, and NIST CSF. By linking policy implementations to specific CSF subcategories, Thriveworks strengthens its evidence base for compliance and risk management activities.

Why this matters: Zero Trust is a foundational strategy for modern cybersecurity, particularly in cloud-first and hybrid environments. Mapping the policy to NIST CSF 2.0 provides measurable assurance that access controls, monitoring, response mechanisms, and identity management practices are both robust and aligned with industry expectations. It also facilitates continuous improvement by identifying any gaps or underrepresented controls for future enhancement.

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.