Encryption Standard

1. Purpose

Operational detail of how Rex Black applies cryptography across its stack. This is the "what goes where" companion to the Cryptography & Key Management Policy.

2. In transit

1. HTTPS everywhere. All Rex Black domains serve exclusively over TLS 1.2 or TLS 1.3; TLS ≤ 1.1 is disabled at the load balancer.
2. HSTS is enabled with a 1-year max-age and includeSubDomains.
3. Internal service-to-service calls within AWS use VPC endpoints and AWS's ambient TLS for API calls.
4. Email: outbound SES is TLS-required with opportunistic enforcement. DKIM and DMARC are configured on all Rex Black sending domains.
5. Database connections (DynamoDB, RDS if introduced) use the AWS-provided TLS endpoints; plaintext endpoints are prohibited.

3. At rest

1. DynamoDB: server-side encryption with alias/rexblack/default KMS key on every table. This is enforced by an IaC policy; tables without customer-managed KMS fail CI.
2. S3: SSE-KMS on every bucket. Public bucket policies are blocked at the account level via Public Access Block.
3. Vault items: envelope-encrypted: payload with AES-256-GCM under a data key; data key wrapped by alias/rexblack/vault; shared-item variants additionally wrapped by each recipient's X25519 public key.
4. SSM Parameter Store: SecureString only, wrapped by alias/rexblack/secrets.
5. Lambda temporary storage: /tmp is treated as ephemeral; nothing sensitive may persist across invocations.
6. Endpoint disk: laptops are required to run FileVault (macOS) or BitLocker (Windows) per the Endpoint Security Policy.

4. In use

1. Secrets are read on-demand, cached in-memory at the Lambda container only for the duration of a request.
2. Sensitive values are never logged. Structured logs use an allow-list of fields; redaction middleware strips known secret patterns.

5. Exports / portability

1. Any export of Confidential or Restricted data leaves Rex Black systems only over an encrypted channel, and only after the receiving system's encryption posture is approved.
2. Physical media (USB drives, CDs) are prohibited for data above Internal unless the device is hardware-encrypted (FIPS 140-2 validated) and the export is logged.

6. FIPS considerations (CMMC / CUI scope)

1. For engagements that touch CUI, AWS KMS satisfies FIPS 140-2. The application-layer vault shall, for CUI scope, route payload encryption through kms:Encrypt/kms:Decrypt rather than local AES-GCM, accepting the latency trade-off. This switch is enabled per-tenant via a feature flag.
2. Where non-FIPS crypto is used on non-CUI data, that fact is documented on the data classification record and reviewed annually.

7. References

• 008-cryptography-and-key-management-policy.md
• 009-data-classification-and-handling-policy.md
• 021-logging-and-monitoring-policy.md

8. Revision history

Version	Date	Author	Approver	Change
1.0	2026-04-17	S.O.	CEO	Initial policy

Approval

This policy has been reviewed and is hereby approved for the named version and effective date above.

Approved by	Myles Bai
Title	Chief Executive Officer, Rex Black LLC
Email	myles@rexblack.com
Approval date	2026-04-17
Effective date	2026-04-17
Next review due	2027-04-17

Digital signature of record: the CEO's electronic approval is captured in the platform audit log (event kind admin.policy.approved) with hash-chained integrity under the M-C1 control. The hash-chained audit log entry for this document is the canonical signature of record; this printed block exists for print/review convenience.