Is Temporal Cloud Safe for Sensitive Data? PCI DSS, SOC 2, HIPAA, and Data Sovereignty Explained

Written by:
Xgrid Temporal Engineering Team
Certified Temporal Partner — Cloud Security, Compliance & Durable Execution

Building resilient, distributed applications in regulated environments presents a fundamental engineering paradox: microservices must process highly sensitive payload data—such as financial transactions, health records, and personally identifiable information (PII)—yet cloud orchestration engines must coordinate state without compromising data privacy. When security and infrastructure teams evaluate Temporal Cloud for production workloads, the primary question is always the same: Is Temporal Cloud safe for sensitive data?

The short answer is yes. Temporal Cloud employs a zero-trust, dual-plane security model that isolates execution control from application data processing. When coupled with client-side encryption via custom Temporal Data Converters, raw payload data never exists in plaintext within Temporal Cloud infrastructure. Learn how Xgrid helps enterprise teams design production-ready, secure Temporal architectures →

Why Temporal Cloud Is Safe for Sensitive Data

When evaluating Temporal Cloud sensitive data security, enterprise compliance teams are inspecting an architecture designed specifically to isolate customer payload data from cloud orchestration storage. Rather than relying solely on cloud-provider disk encryption, Temporal Cloud secures mission-critical workloads by enforcing end-to-end client-side encryption using custom Temporal Data Converters and customer-hosted Codec Servers. As a result, sensitive payloads are encrypted inside the customer’s private network before reaching Temporal Cloud, leaving only encrypted byte arrays in persistent state storage. This framework is backed by an audited SOC 2 Type II report, HIPAA Business Associate Agreements (BAAs), and complete PCI DSS alignment.

Adopting cloud workflow orchestration without a clear data isolation pattern creates significant compliance hurdles across regulated sectors:

• Fintech & Payment Processing: Coordinating multi-step ledger updates, gateway retries, and KYC onboarding without exposing Primary Account Numbers (PAN) or banking credentials to external storage. See how Temporal supports durable fintech payment workflows →
• Healthcare & Life Sciences: Automating HIPAA-compliant patient scheduling, clinical trial data processing, and claims pipelines while guaranteeing that Protected Health Information (PHI) is never stored in plaintext on vendor disks.
• Global Data Sovereignty: Complying with strict regional mandates, such as GDPR Article 44, by restricting workflow event history storage to designated AWS or GCP regions while maintaining distributed worker fleets. We’ve helped teams migrate safely to Temporal Cloud — read the USIS case study →

How Temporal Cloud Architecture Isolates Sensitive Data

Understanding Temporal Cloud dual-plane architecture requires looking at how workflow orchestration logic is decoupled from application data processing. Temporal Cloud operates exclusively as a control plane—managing execution state, activity scheduling, task queues, and timers—while application code runs on workers hosted entirely within your private cloud or on-premise infrastructure. All network communication between customer workers and Temporal Cloud namespaces is encrypted in transit over mutual TLS (mTLS) via port 7233. Because the control plane never executes application code or inspects decrypted state payloads, your internal tokens, database credentials, and business logic remain strictly within your data plane.

For official platform security specifications, refer to the Temporal Cloud security documentation.

The Dual-Plane Architecture Split

• Control Plane (Temporal Cloud): Coordinates workflow state machines, signals, timers, activity scheduling, and event histories. It receives only mTLS-authenticated gRPC requests containing binary protobuf messages (Payload.data).
• Data Plane (Your Infrastructure): Hosts application logic, activity handlers, database connections, and cryptographic keys. Customer-managed workers pull tasks from Temporal Cloud over mTLS, process logic locally, and return encrypted results.

Because application code executes exclusively on your self-hosted workers, raw business payloads, API secrets, and database connections never touch Temporal Cloud servers.

Client-Side Encryption with Temporal Data Converter and Codec Server

Implementing Temporal Data Converter client-side encryption provides a cryptographic shield that encrypts workflow inputs, outputs, activity parameters, and memo fields before transmission to Temporal Cloud. This framework operates on a zero-trust model: raw application payloads exist in plaintext only inside self-hosted worker memory and authorized developer browsers. By configuring an AES-256-GCM payload converter on worker SDKs paired with an HTTP Codec Server for Web UI decoding, teams ensure that Temporal Cloud persists encrypted Payload protobuf messages without ever possessing the keys to decode them.

Working reference implementations are available in the official Temporal data conversion guides and the temporalio/samples-go encryption repository. Additional open-source tooling is available via github.com/XgridInc.

Step 1: Implementing Custom Payload Encryption in Go

The Go implementation below demonstrates custom payload encryption using AES-256-GCM before data leaves the worker process:

package security

import (

"crypto/aes"

"crypto/cipher"

"crypto/rand"

"fmt"

"io"

commonpb "go.temporal.io/api/common/v1"

"go.temporal.io/sdk/converter"

)

// CryptDataConverter wraps the default DataConverter with AES-256-GCM encryption.

type CryptDataConverter struct {

parent converter.DataConverter

key    []byte // 32-byte secret key for AES-256

}

func NewCryptDataConverter(parent converter.DataConverter, key []byte) converter.DataConverter {

return &CryptDataConverter{

parent: parent,

key:    key,

}

}

func (c *CryptDataConverter) ToPayload(value interface{}) (*commonpb.Payload, error) {

// Serialize object to default JSON payload

unencryptedPayload, err := c.parent.ToPayload(value)

if err != nil {

return nil, err

}

block, err := aes.NewCipher(c.key)

if err != nil {

return nil, fmt.Errorf("cipher init failure: %w", err)

}

gcm, err := cipher.NewGCM(block)

if err != nil {

return nil, fmt.Errorf("gcm init failure: %w", err)

}

nonce := make([]byte, gcm.NonceSize())

if _, err := io.ReadFull(rand.Reader, nonce); err != nil {

return nil, fmt.Errorf("nonce generation failure: %w", err)

}

// Encrypt serialized payload bytes

encryptedData := gcm.Seal(nonce, nonce, unencryptedPayload.GetData(), nil)

return &commonpb.Payload{

Metadata: map[string][]byte{

"encoding": []byte("binary/encrypted"),

},

Data: encryptedData,

}, nil

}

Caption: AES-256-GCM Temporal Data Converter encrypting workflow payloads before transmission.

Step 2: Establishing mTLS Worker Client Connection

Workers authenticate to Temporal Cloud namespaces using mutual TLS certificates. For certificate issuance guidelines and CA configuration, see Temporal Cloud certificates.

package main




import (

"crypto/tls"

"log"




"go.temporal.io/sdk/client"

"go.temporal.io/sdk/converter"

"yourproject/security"

)




func ConnectSecureClient() (client.Client, error) {

// Load mTLS client keypair for Temporal Cloud namespace authentication

cert, err := tls.LoadX509KeyPair("config/certs/client.pem", "config/certs/client.key")

if err != nil {

log.Fatalf("Failed to load mTLS keypair: %v", err)

}




tlsConfig := &tls.Config{

Certificates: []tls.Certificate{cert},

ServerName:   "production-namespace.tmprl.cloud",

}




// Fetch 32-byte key from AWS KMS or HashiCorp Vault — never hardcode secret keys

encryptionKey, err := loadKeyFromKMS()

if err != nil {

return nil, err

}




return client.Dial(client.Options{

HostPort:  "production-namespace.tmprl.cloud:7233",

Namespace: "production-namespace.a1b2c",

ConnectionOptions: client.ConnectionOptions{

TLS: tlsConfig,

},

DataConverter: security.NewCryptDataConverter(

converter.GetDefaultDataConverter(),

encryptionKey,

),

})

}

Caption: Go client connecting over mTLS with a globally registered encrypted Data Converter.

The Role of the Codec Server in Secure Debugging

When developers inspect running workflows via the Temporal Web UI or CLI (tcld), Temporal Cloud requests payload decoding from an HTTP Codec Server hosted inside the customer’s private network:

1. The Temporal Web UI fetches the encrypted payload (binary/encrypted) from event history.
2. The browser sends the encrypted payload directly to the customer-hosted Codec Server.
3. The Codec Server verifies the user’s SSO/OAuth2 bearer token.
4. If authorized, the Codec Server decrypts the payload locally and returns JSON to the browser.
5. Plaintext data flows directly from Codec Server to the developer’s browser—it never touches Temporal Cloud storage.

Review the official Temporal Codec Server documentation when implementing decode endpoints.

Temporal Cloud Compliance Framework: SOC 2 Type II, HIPAA, and PCI DSS

Achieving Temporal Cloud enterprise compliance involves leveraging a certified operational security baseline governing data privacy, access control, and regulatory alignment. Temporal Cloud enables regulated healthcare, financial, and e-commerce enterprises to run core business workflows while satisfying SOC 2 Type II, HIPAA, and PCI DSS requirements. Enterprise customers can execute Business Associate Agreements (BAAs) for healthcare workloads and access independent SOC 2 Type II audit reports covering Security, Availability, and Confidentiality. When client-side Data Converters are enabled, financial workflows achieve PCI DSS alignment by keeping cardholder data completely out of cloud storage scope.

SOC 2 Type II Certification

Temporal maintains an active SOC 2 Type II audit report issued by independent third-party auditors. The audit evaluates controls across:

• Logical access enforcement, mTLS authentication, and RBAC policies.
• Vulnerability management, continuous monitoring, and incident response runbooks.
• High availability, automated database backups, and multi-region failover mechanisms.

HIPAA Compliance and BAA Execution

Temporal Cloud fully supports healthcare organizations processing Protected Health Information (PHI):

• Business Associate Agreement (BAA): Temporal enters into BAAs with enterprise customers to fulfill HIPAA mandates.
• PHI Isolation: Combining mTLS transit security with client-side Data Converters ensures that zero unencrypted PHI is persisted within Temporal Cloud databases.

PCI DSS Alignment for Fintech Workflows

For financial institutions, payment gateways, and banking platforms:

• Audit Scope Reduction: Encrypting Payment Card Industry (PCI) payload fields (e.g., Primary Account Numbers) on workers removes Temporal Cloud from primary PCI DSS storage audit boundaries.
• Transit Protection: Mandatory mTLS 1.3/1.2 channels satisfy PCI DSS Requirement 4 (encrypting cardholder data across open, public networks).

Managing Data Sovereignty and Multi-Region Residency in Temporal Cloud

Temporal Cloud data sovereignty provides geo-residency management that restricts workflow history and state metadata storage to specific geographic cloud regions. This capability allows global organizations to comply with strict regional mandates, such as GDPR Article 44, by pinning namespaces to designated AWS or GCP regions. Customers select target primary and secondary storage regions during namespace provisioning, guaranteeing that persistent event history remains within required physical borders. Temporal Cloud Multi-Region Namespaces provide high-availability failover resilience across pre-approved region pairs while maintaining local data storage policies.

Key Data Residency Features

• Explicit Cloud Region Pinning: Namespaces are explicitly provisioned within designated AWS (e.g., us-east-1, eu-west-1) or GCP regions.
• Multi-Region Failover Controls: High-Availability (HA) multi-region namespaces replicate state metadata exclusively between customer-approved region pairs.
• GDPR Transfer Isolation: Pinning event history storage to EU regions while encrypting worker payloads fulfills European Union General Data Protection Regulation (GDPR) cross-border transfer requirements.

For teams migrating from self-hosted clusters to Temporal Cloud under strict sovereignty constraints, dual-run cutovers ensure zero downtime. How to migrate Temporal workflows from on-prem to Cloud without downtime →

Troubleshooting Security & Encryption Failure Modes

Temporal workflow failure debugging for sensitive workloads usually centers on encryption or certificate misconfigurations rather than cloud infrastructure outages. The failure matrix below details primary operational issues and verified fixes.

How to Implement Temporal Cloud Security Controls

Rolling out a secure Temporal Cloud production environment involves a systematic hardening sequence that translates dual-plane isolation into enforceable operational controls. This process guarantees that certificate lifecycle management, payload encryption, Codec Server authentication, data residency, and audit logging are fully verified prior to live traffic cutover.

Implementation Steps

1. Namespace & mTLS Setup: Provision a Temporal Cloud namespace in your required cloud region (AWS or GCP) and configure mTLS authentication using short-lived X.509 client certificates.
2. Global Data Converter Injection: Implement an AES-256-GCM (or KMS-backed) DataConverter and register it globally across all workflow starters, workers, and activity handlers.
3. Private Codec Server Deployment: Deploy a Codec Server within your private network, enforce OAuth2/SSO token validation, and configure Web UI codec settings.
4. Search Attribute Sanitization: Restructure Search Attributes so they store only non-sensitive correlation IDs; ensure raw PII/PHI/PAN fields remain strictly inside encrypted payloads.
5. SIEM Audit Logging: Export Temporal Cloud audit logs to CloudWatch, Datadog, or Splunk to alert on mTLS failures, certificate expirations, and unauthorized Codec Server requests.
6. Compliance Validation: Run an end-to-end canary workflow with synthetic sensitive fields, confirm event history contains only ciphertext, and verify Web UI decoding behavior.

Production Checks, Testing, and Observability

Before production promotion, validate:

• Production Checks: Certificate rotation automation verified; KMS/Vault key permissions limited to worker service accounts; namespace RBAC least-privilege enforced; Codec Server non-public.
• Testing: Integration tests assert binary/encrypted payload headers; negative tests confirm workers without encryption converters fail safely; chaos test worker restarts during encrypted activity processing.
• Observability: Monitor task queue backlog, worker saturation, mTLS failure rate, Codec Server decoding latency, and audit log lag.

Large encrypted payloads can still encounter Temporal Cloud payload size thresholds. Pair client-side encryption with Temporal External Storage for large payload limits when processing large PDFs, medical imaging, or LLM traces.

The table below maps specific regulatory requirements directly to Temporal Cloud mechanisms and implementation methods.

Common Mistakes When Securing Temporal Cloud

Enforcing Temporal Cloud security governance requires continuous validation of encryption policies, certificate lifecycles, and access controls across all environments. Avoiding common misconfigurations ensures that plaintext sensitive data never reaches cloud state storage.

Mistake 1: Storing Plaintext PII/PHI in Search Attributes

Search Attributes are indexed by Temporal Cloud to enable workflow queries (WorkflowListExecutions). Attaching sensitive fields like social security numbers or credit card numbers to Search Attributes exposes those values in plaintext within the search index.

Fix: Pass only non-sensitive identifiers (e.g., hashed UUIDs like CustomerUUID) in Search Attributes. Keep raw PII/PHI inside encrypted payloads.

// GOOD: Using non-sensitive hashed UUID for Search Attributes

workflow.UpsertTypedSearchAttributes(ctx,

keyword.ValueSet("CustomerUUID", hashedCustomerID),

)

// BAD: Never pass raw sensitive data into Search Attributes

// workflow.UpsertTypedSearchAttributes(ctx, keyword.ValueSet("SSN", rawSSN))

Mistake 2: Exposing Unauthenticated Codec Servers to Public Networks

Exposing an HTTP Codec Server without OAuth2/JWT token verification allows anyone with payload URLs to decrypt sensitive workflow histories.

Fix: Enforce SSO/OAuth2 bearer token verification on the Codec Server endpoint and restrict access to private networks or VPNs.

Mistake 3: Hardcoding Long-Lived Client Certificates

Embedding 10-year mTLS certificates into container images creates a critical vulnerability if credentials leak.

Fix: Deploy cert-manager or HashiCorp Vault to issue short-lived mTLS client certificates, automating rotation via tcld.

Mistake 4: Inconsistent Global Data Converter Configuration

Registering encrypted Data Converters on workflow clients while omitting them on worker nodes or activity handlers causes deserialization failures in production.

Fix: Enforce a unified client factory that registers the encrypted Data Converter globally across all SDK instances.

Fix: Enforce a unified client factory that registers the encrypted Data Converter globally across all SDK instances [2].

Mistake 5: Logging Decrypted Payloads in Workers

Debug-logging activity arguments after decryption leaks plaintext PII/PHI into centralized logging platforms, defeating PCI/HIPAA isolation.

Fix: Redact payload bodies in worker loggers; log only workflow IDs, run IDs, and non-sensitive correlation keys.

Mistake 6: Relying Solely on Platform Data-at-Rest Encryption

Cloud provider AES-256 disk encryption protects physical drives but does not prevent cloud operators or compromised control planes from viewing plaintext payloads.

Fix: Always combine Temporal Cloud with client-side Data Converter encryption for regulated workloads.

Frequently Asked Questions

Is Temporal Cloud safe for sensitive data?

Yes. Temporal Cloud is safe for sensitive data when configured with client-side Data Converters, encrypting all workflow inputs, outputs, and activity parameters before transmission. Temporal Cloud is SOC 2 Type II certified, supports HIPAA BAAs, and enables PCI DSS scope reduction.

Can Temporal Cloud see my workflow payload data?

No. When a custom Temporal Data Converter with client-side encryption is implemented, Temporal Cloud receives only encrypted byte arrays. Decryption keys reside exclusively within your application workers and your self-hosted Codec Server.

Is Temporal Cloud HIPAA compliant?

Yes. Temporal Cloud is HIPAA compliant, and Temporal will enter into a Business Associate Agreement (BAA) with healthcare customers. Implementing end-to-end payload encryption guarantees that Protected Health Information (PHI) is never stored in plaintext on Temporal Cloud infrastructure.

How does Temporal Cloud support PCI DSS compliance?

Temporal Cloud supports PCI DSS compliance by enforcing mandatory mTLS for all network connections and enabling complete client-side payload encryption. Because payment card data is encrypted on customer workers before transmission, Temporal Cloud remains out of scope for cardholder data storage.

What is the purpose of a Temporal Codec Server?

A Temporal Codec Server is a user-hosted HTTP service that decodes encrypted workflow payloads for display in the Temporal Web UI or CLI (tcld). It runs within your network boundary, verifies user authorization, and returns decrypted JSON directly to authorized browsers without passing through Temporal Cloud.

Where is my data stored in Temporal Cloud?

Temporal Cloud stores state data and execution history within customer-selected cloud provider regions (AWS or GCP). Organizations select specific primary and secondary regions during namespace creation to satisfy local data sovereignty and GDPR mandates.

What happens if a Temporal Cloud region experiences an outage?

Temporal Cloud supports Multi-Region Namespaces that automatically replicate workflow execution state between pre-approved region pairs. In the event of a cloud region outage, workflow execution fails over to the secondary region without losing state or breaking deterministic replay.

Do I still need Temporal External Storage if payloads are encrypted?

Yes, if individual payloads approach Temporal Cloud size thresholds. Encryption does not compress data; large OCR documents, medical imaging, or LLM traces should use Temporal External Storage to keep event history lean while maintaining key control.

The Bottom Line: Zero-Trust Workflow Security at Scale

By combining Temporal Cloud’s dual-plane architecture, mandatory mTLS authentication, and client-side Data Converters, enterprise engineering teams achieve complete data isolation without sacrificing the benefits of a fully managed cloud service. Your workflow payloads remain encrypted under your key control, your compliance scope stays minimized, and your state machines execute reliably at scale.

Evaluating Temporal Cloud for sensitive workloads requires rigorous mTLS lifecycle management, custom Data Converter engineering, and compliance verification. Xgrid is a certified Temporal partner offering structured technical assessments covering Data Converter implementation, Codec Server deployment, and SOC 2/HIPAA namespace auditing. Request a Temporal Cloud Security & Compliance Assessment →

Further reading:Temporal workflows in production field operations whitepaper · Temporal Cloud security documentation.