New Relic HIPAA Compliance: BAA, PHI, and Configuration Best Practices

Using New Relic in a HIPAA-regulated environment is feasible when you combine an executed Business Associate Agreement (BAA) with disciplined configuration and day‑to‑day controls. You remain the covered entity (or business associate) responsible for how telemetry is collected, transformed, stored, and accessed.

Once HIPAA is activated, you must use only HIPAA-eligible services, prevent Protected Health Information (PHI) from entering non-permitted fields, enforce log obfuscation, and align ingestion and storage with data region compliance. HIPAA support restrictions also apply—never include PHI in support tickets, screenshots, or free‑form text.

New Relic's HIPAA Compliance Overview

New Relic provides a platform that can support HIPAA obligations when you sign a BAA and configure accounts to limit data types, features, and user access. Compliance is a shared responsibility: New Relic offers technical and contractual controls, while you design telemetry patterns so PHI is never transmitted unless explicitly allowed by your BAA.

In practice, you will: (1) execute a BAA, (2) enable or provision HIPAA-enabled accounts, (3) restrict usage to HIPAA-eligible services, (4) configure encryption in transit (for example, TLS 1.2 encryption or higher), (5) define data region placement, and (6) operationalize access, retention, and redaction policies across environments.

• Contractual guardrails: BAA defines permitted uses/disclosures and vendor obligations.
• Technical guardrails: data region compliance, transport security, at‑rest protection, role-based access, and auditability.
• Operational guardrails: secure development practices, PHI minimization, and HIPAA support restrictions for all staff.

Business Associate Agreement Requirements

Prerequisites before enabling HIPAA

• Executed Business Associate Agreement (BAA) covering your intended use of the platform.
• Clear data inventory defining which signals may contain PHI and which must be irreversibly obfuscated.
• Chosen hosting geography to satisfy data region compliance obligations.
• Documented access model (SSO/SAML, MFA, least privilege) and auditing approach.
• Retention standards that meet your legal and risk thresholds.

Activation steps

• Provision HIPAA-enabled accounts tied to your BAA; separate them from non‑regulated projects.
• Confirm the list of HIPAA-eligible services you will use and disable non‑eligible features.
• Establish ingestion controls (drop rules, redact/obfuscate transforms) to prevent PHI leakage.
• Enforce SSO/MFA, scoped API keys, and role-based access before any production data flows.
• Run pre‑production tests to validate “no PHI” assertions across logs, traces, events, and metrics.

Ongoing obligations

• Review service eligibility and configuration at least annually and after major product changes.
• Maintain incident response runbooks specific to telemetry data exposures.
• Train staff on HIPAA support restrictions—never transmit PHI in support communications.

HIPAA-Eligible New Relic Services

Only services designated as HIPAA-eligible in your executed BAA are in scope. Eligibility is feature‑specific and can vary over time, so you should validate coverage for each capability you plan to use.

Typical service categories used in HIPAA programs

• Application and service performance telemetry (metrics and spans) without request/response bodies that contain PHI.
• Infrastructure and host metrics that exclude identifiers and sensitive payloads.
• Log management with enforced log obfuscation and strict field-level redaction.
• Synthetics and browser telemetry configured to avoid capturing end‑user identifiers or page content containing PHI.
• Alerts, dashboards, and query features that operate on sanitized data sets.

Eligibility checklist

• Does the feature ever capture free‑form text or payload bodies? If yes, disable or redact before ingestion.
• Can you restrict data to a permitted region and storage class for data region compliance?
• Are PHI fields guaranteed to be removed, tokenized, or irreversibly hashed?
• Is the feature explicitly named as a HIPAA-eligible service in your BAA?

Data Handling and PHI Protection

Identify and minimize PHI

Direct identifiers (name, full address, email, phone, SSN, medical record numbers) and any data that can be combined to identify an individual are PHI when tied to health information. Your default posture should be to exclude or transform these fields before telemetry leaves your network.

Recommended protections

• Tokenize subject identifiers; store the mapping in a system of record, not in observability tools.
• Hash incidental identifiers (for example, irreversible SHA‑256 with a rotation schedule) when correlation is required.
• Drop HTTP request/response bodies and query strings unless you can provably remove PHI.
• Use structured logging with strict schemas; ban free‑form text in production logs.
• Apply retention limits and automated deletion for data categories most likely to contain PHI.

Access and oversight

• Enforce least‑privilege RBAC and SSO/MFA; review access quarterly.
• Enable auditability for configuration changes, API key creation, and data export events.
• Create saved queries to continuously verify that PHI patterns are absent from stored data.

Configuration Best Practices for HIPAA

Account and org settings

• Place accounts in the correct geography for data region compliance and restrict cross‑region features.
• Require SSO/SAML and MFA; disable local passwords; provision users via SCIM where available.
• Constrain API keys to least privilege; rotate keys and disable unused keys automatically.
• Disable non‑eligible services globally and lock configuration with admin-only change control.

Agent and pipeline hardening

• Use the latest agents and enable secure/high‑security modes; turn off payload/body capture.
• Strip headers and parameters known to carry identifiers (for example, Authorization, Cookie, email, phone).
• Implement upstream redaction in log forwarders and APM middleware before data exits your VPC.
• Segregate dev/test from prod; never mirror live PHI into lower environments.

Operations

• Create canary datasets to test redaction rules pre‑deployment.
• Alert on ingestion anomalies (sudden growth in log volume, new fields, or failed obfuscation counters).
• Document and rehearse data‑handling runbooks, including rapid field‑level quarantine and purge.

Log Obfuscation Techniques

Log obfuscation prevents PHI and other sensitive values from reaching storage. Combine multi‑layer redaction: at the source application, in your log/trace pipeline, and—if needed—at destination via ingestion rules.

High‑risk patterns to scrub

• Names, emails, phone numbers, physical addresses.
• Medical record numbers (MRNs), claim IDs, appointment IDs.
• US SSNs and government IDs, insurance policy numbers.
• Tokens and secrets (JWTs, API keys, session IDs).

Example redaction patterns (engine-agnostic)

# Email
(?i)\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b -> [REDACTED_EMAIL]