Personally Identifiable Information

The controls below encrypt personal data in transit and at rest, bound where payloads persist and keep them out of logs. They apply to GDPR, HIPAA and PDPA, and the same controls serve CCPA, LGPD, POPIA and similar laws.

The organization that operates the environment is the data controller or data processor.

Roles

The operating organization:

• Answers data subject requests (access, rectification, erasure)
• Maintains records of processing activities
• Signs data processing agreements with its customers and vendors
• Reports breaches to supervisory authorities

Zato Source has no access to the data that flows through an environment that you install and operate.

Where data lives

The configuration database (ODB) stores configuration and security definitions - channels, outgoing connections and credentials. It stores no message payloads.

Requests and responses exist in memory for the duration of a request and are gone when the response is sent.

Payloads persist in two places:

• The audit log, which keeps events for 30 days
• Publish/subscribe queues, where messages wait until they are delivered or expire

Server logs record metadata about traffic, such as which service handled a request, not payloads.

In transit and at rest

• Servers expose TLS ports for API traffic and the Dashboard. Minimum protocol versions and cipher suites are configurable. Publish 8184 and 11224, do not publish 8183 and 11223, when plaintext must be closed
• Channels can require SSL/TLS
• HL7 v2 over MLLP can run over TLS with TLS 1.2 as the minimum and with optional mutual TLS, on both the receiving and the sending side
• HL7 FHIR connections use Basic Auth, OAuth and TLS
• Connections to audit log databases support TLS, including mutual TLS with client certificates
• Outgoing connections to REST or FHIR servers support TLS with configurable certificate validation

At rest:

• The ODB stores secrets, such as connection passwords, encrypted with Fernet under the zato.secf. prefix
• The secret key can come from a file, an environment variable or stdin
• Environment backups uploaded to cloud storage are encrypted with AES-GCM before upload, using a key derived from a password with Argon2
• Server logs and pub/sub queue files use the storage encryption of the operating system or cloud provider

Access and logs

• Channels take API keys, Basic Auth, NTLM, Bearer tokens or WS-Security, and security definitions can be grouped and reused
• Outgoing connections use the same kinds of security definitions
• Rate limiting and IP filtering cap how many requests a caller can send and drop traffic from named address ranges
• A password that you do not set is generated as a uuid4 - see security defaults
• Services encrypt, hash and generate secrets through the cryptography APIs
• A service can strip, mask or tokenize PII fields before they reach a downstream system. MCP gateways can scan tool responses for national identity numbers, IBANs and other identifiers and replace each match with a token, per MCP response controls
• Per-request log lines contain the HTTP method, URI, service name, payload length and remote address, not payloads. Secrets in logged configuration and query strings are stored as ******
• server.log and http_access.log rotate at Zato_Server_Log_Max_Size, 1 GB by default, and keep Zato_Server_Log_Backup_Count copies, 2 by default. A container reads both variables when the environment is created, so set them before the first start
• Logs can stream to remote aggregation platforms. A remote log service processes whatever is shipped to it
• In services, log correlation IDs (CIDs) rather than raw payloads
• When a new release is available, the Dashboard shows an Updates available button - see installing updates

Retention and data-subject rights

The audit log is where full request and response payloads persist. It records traffic of user-defined REST and SOAP channels, outgoing connections, publish/subscribe, IMAP and X12. The MCP audit log records payload sizes, not payloads.

• The log keeps events for 30 days and deletes older events automatically
• The log runs on SQLite inside the container by default, or on MySQL, PostgreSQL and Oracle DB outside of the container, with TLS to each
• The log records user-defined objects and skips platform-internal traffic

The other stores are bounded too:

• Pub/sub messages expire after one day by default
• HL7 MLLP deduplication entries expire after a configurable time-to-live
• Cache entries expire per their configured TTLs

Erasure from Zato is through those retention windows. For the systems that Zato connects, a service can locate a person's data across backends, export it for access and portability requests, and invoke each backend's deletion API for erasure.

Mapping to regulations

GDPR:

• Article 17 (right to erasure) - bounded retention of the audit log and pub/sub messages, and integration services for erasure across connected systems
• Article 25 (data protection by design) - payloads persist in the audit log and pub/sub queues, generated passwords, and PII minimization in flight
• Article 30 (records of processing) - the audit log as the record of what flowed where and when
• Article 32 (security of processing) - TLS in transit, encryption at rest and access control

HIPAA:

• Technical safeguards - access control, transmission security with TLS and mutual TLS, and audit controls through the audit log
• The minimum necessary rule - services that strip or mask PHI before it reaches systems that do not need it

PDPA:

• Protection obligation - the transit, at rest and access control mechanisms above
• Retention limitation obligation - automatic retention bounds on every place where payloads persist

See also

Learn more