Third-party management

We take protecting the security of the sensitive data we manage seriously. This responsibility goes beyond the code we write and systems we manage, to include all external products, applications, tools, and service providers.

Before onboarding a new third party (or materially changing the relationship with an existing third party), we evaluate whether the level of security is commensurate with the risk posed and the stated purpose/business benefit.

Our Security team considers many factors in this evaluation process, including:

• the type of data shared with or accessible to the third party (i.e., PHI, PII, code, customer information, security information);
• the entity’s compliance and certifications (i.e., HIPAA-compliant, HITRUST-certified, SOC2-certified); and
• the entity’s security features and controls.

We assess and manage third parties based on the level of risk we assume by engaging. Risk designations comprise data risk and control.

We have three categories of data risk for a third party:

1. High: The third party has (a) access to PHI or other highly sensitive data; (b) ability to edit our code base; and/or (c) ability to manage access or credentials to sensitive systems.
2. Medium: The third party has (a) access to other sensitive data, e.g., financial information, personnel information, customer business information like integration partners or settings; (b) read-only access to the code base; and/or (c) security appliances.
3. Low: The third party doesn't have access to data described as medium or high risk.

We either have internal or external control of third parties:

1. Internal. We control third-party vendors and tools. For example:
   • We typically have tools installed on our own infrastructure, although this isn't strictly necessary.
   • We have full administrative control over any vendor (e.g., access to audit logs).

2. External. We don't control third-party vendors or tools.

Our Security team requires an annual audit of third parties in our inventory. The audit includes:

1. whether the third party potentially contains PHI;
2. whether the "information supply chain" of our production services depends on third-party data; or
3. whether the third-party type is within the allowable scope (i.e., Core Productivity Platform, SaaS Platform, Infrastructure Supplier, or Service Provider).

Our Security team gauges whether the risk associated with the third-party relationship has changed since onboarding. We review both internal and external factors since how we configure and use the third party often influences risk as much—if not more than—the security posture of the given third party.

The annual audit identifies and confirms:

• our internal application owner or stakeholder;
• the contact information for the third party;
• the types of data stored or shared, as compared to the initial evaluation;
• the user base, as compared to the initial evaluation;
• any integrated systems, as compared to the initial evaluation;
• the authentication method and enforcement, whether SSO or MFA;
• the original third-party security assessment;
• the maintenance of security certifications for the third party;
• the requirements for disaster recovery and business continuity;
• compliance to SLAs; and
• the Business Associate Agreement (BAA).

For cloud service providers and network or communications service providers, we verify our adherence to the agreed-upon shared security responsibility model. Read the shared security responsibility model.