Encryption & Key Management

Encryption at rest

Debtor PII — including name, phone number, email address, and postal address — is encrypted using AES-256-GCM at the field level. This means the data is encrypted before being written to disk, not merely at the database or volume layer. Field-level encryption ensures that even with direct database access, individual PII fields cannot be read without the corresponding key.

AES-256-GCM provides authenticated encryption: in addition to confidentiality, the algorithm includes an authentication tag that detects tampering. Any modification to the ciphertext will cause decryption to fail, providing integrity assurance as well as confidentiality. The 256-bit key size is well beyond current computational attack capability.

Encryption in transit

All data transmitted between Merion's systems and users' devices is encrypted using TLS 1.2 as a minimum. TLS 1.3 is used where both parties support it. Cipher suite configuration is restricted to suites that provide forward secrecy — specifically ECDHE-based suites — so that a future compromise of a private key cannot be used to decrypt past recorded sessions.

HTTP Strict Transport Security (HSTS) is enforced with a max-age of one year, preventing browsers from making non-encrypted connections to Merion's domains. Internal service-to-service traffic is also encrypted: there are no plaintext channels carrying PII or financial data within Merion's infrastructure.

Key management

Encryption keys are stored separately from the data they protect. Keys and ciphertext are not co-located on the same disk or in the same secrets store — this separation limits the impact of a storage breach to ciphertext that cannot be decrypted without the separately held keys.

Key management follows a separation-of-duties principle: the processes and roles that handle encryption keys are distinct from those that access encrypted data. Keys are rotated on a scheduled basis; rotation events are recorded in the audit trail. After rotation, old keys are retained only for the purpose of decrypting legacy records encrypted under those keys. When those records reach their retention end date and are destroyed, the associated old keys are retired.

Key access

Access to encryption keys is restricted to authorised systems and a small number of authorised personnel — for example, on-call engineering staff responding to a security incident. Key access is authenticated through Merion's OIDC single sign-on, and all key access events are logged in the audit trail.

What is not encrypted

Not all operational data is encrypted at rest. Non-sensitive data — such as case reference numbers, debt amounts, and account status flags — is stored unencrypted to support query performance. This data does not contain PII and is not personally identifiable without combination with the encrypted PII fields.

A note on hardware security modules

Hardware security modules (HSMs) are considered best practice for encryption key storage in high-security environments. They provide tamper-resistant physical key storage and enforce access controls at the hardware level. Merion's current key management approach is designed to achieve equivalent separation-of-duties and access control outcomes within its existing infrastructure. The use of HSMs will be evaluated as Merion's platform and data volumes scale.

Related pages

For an overview of Merion's full security architecture, see Security. For the legislative obligations that underpin these controls, see Security of Personal Information (APP 11).