# Encryption Policy

**Digital Benefits Pte Ltd (WiBiz)**
**Document ID:** WBZ-SEC-002
**Version:** 1.0 | **Effective Date:** 15 April 2026 | **Review Date:** 15 April 2027
**Classification:** Internal | **Owner:** Data Protection Officer
**Approved by:** Nicklaus D'Cruz, CEO

---

## 1. Purpose

This policy defines requirements for the use of cryptographic controls to protect the confidentiality and integrity of WiBiz data. It applies to all data processed, stored, or transmitted by WiBiz systems.

---

## 2. Scope

All WiBiz-managed systems and data including: the core CRM platform, cloud hosting infrastructure, payment processing integrations, customer conversation logs, booking and contact data, backups, AI service interactions, and internal communications. This policy applies to all employees, contractors, and agents of WiBiz regardless of location.

---

## 3. Encryption at Rest

### 3.1 Minimum Standards

- All stored customer data must be encrypted at rest using AES-256 or equivalent.
- This applies to: databases, file storage, backups, logs containing PII, and exported data files.
- Encryption at rest must be enabled at the storage layer. Where platform-managed encryption is available, it must be verified as active.

### 3.2 Specific Requirements

| Data Type | Encryption Requirement |
|---|---|
| Customer PII (names, emails, phone numbers) | AES-256 at rest, mandatory |
| Conversation logs and chat history | AES-256 at rest, mandatory |
| Booking and appointment data | AES-256 at rest, mandatory |
| Payment references and transaction IDs | AES-256 at rest, mandatory |
| Health-related data (HSKD verticals) | AES-256 at rest, mandatory; additional access controls and audit logging |
| Authentication credentials (passwords) | Hashed using bcrypt or Argon2; never stored in plaintext |
| API keys and tokens | Encrypted environment variables; never in source code |
| System backups | AES-256 at rest, mandatory |
| Voice recordings | AES-256 at rest, mandatory |
| E-signatures and contracts | AES-256 at rest (provider-managed); tamper-evident seals maintained |
| Internal operational data (non-PII) | AES-256 at rest, recommended |
| Development and staging databases | AES-256 at rest, mandatory (may contain production-like data) |

---

## 4. Encryption in Transit

### 4.1 Minimum Standards

- All data transmitted over networks must use TLS 1.2 or higher. TLS 1.3 is preferred where supported.
- TLS 1.0 and 1.1 are prohibited.
- HTTPS is required for all web-facing services, APIs, and webhooks.
- Internal service-to-service communication must use TLS where technically feasible.
- HSTS headers must be enabled on all WiBiz domains.

### 4.2 Certificate Requirements

- TLS certificates must use RSA 2048-bit keys or ECDSA P-256 as a minimum.
- Certificates must use SHA-256 or stronger signing algorithms.
- Self-signed certificates are prohibited in production environments.
- Certificates must be issued by a trusted Certificate Authority.
- Wildcard certificates are permitted but must be stored and managed with the same controls as private keys.

### 4.3 API and Webhook Security

- All API endpoints exposed by WiBiz must enforce HTTPS.
- Webhook payloads sent to or received from third-party services must be transmitted over HTTPS.
- API authentication tokens must be transmitted only in request headers, never in URLs or query parameters.

### 4.4 SSH Connections

- SSH connections must use Ed25519 or RSA-4096 keys.
- Password-only SSH authentication is prohibited.
- FTP is prohibited; SFTP or HTTPS must be used for file transfers.

---

## 5. Messaging Channel Encryption

- WhatsApp communications use the platform's native end-to-end encryption. WiBiz does not disable or bypass this.
- Web chat widgets served by WiBiz must be loaded over HTTPS.
- Voice data transmitted through AI voice services must use encrypted transport (TLS/SRTP).
- Where end-to-end encryption is not natively available on a channel, TLS in transit is the minimum requirement.
- Message content stored in the platform infrastructure after delivery is subject to the at-rest encryption standards in Section 3.

---

## 6. Key Management

### 6.1 Principles

- Encryption keys must not be stored alongside the data they protect.
- Keys must not be hardcoded in source code, configuration files committed to version control, or environment variables visible in logs.
- Key access is restricted to authorised personnel and service accounts on a need-to-use basis.
- Keys must be generated using cryptographically secure random number generators (CSPRNG).

### 6.2 Key Lifecycle

| Stage | Requirement |
|---|---|
| Generation | Keys generated using cryptographically secure methods (CSPRNG). |
| Storage | Keys stored in platform-managed key services or approved secrets managers. |
| Rotation | See Section 6.4 for rotation schedule. |
| Revocation | Compromised keys revoked immediately. Affected data re-encrypted with new keys. |
| Destruction | Retired keys destroyed using secure deletion. Destruction logged. Data encrypted with destroyed keys re-encrypted or securely deleted. |

### 6.3 Secrets Management

- Application secrets (API keys, database credentials, service tokens) are stored in the hosting platform's environment variable system or an approved secrets manager.
- Secrets are never committed to code repositories.
- Secrets are never transmitted via email, chat, or other unencrypted channels.
- Access to secrets management systems requires MFA.

### 6.4 Key Rotation Schedule

| Key Type | Rotation Frequency |
|---|---|
| API keys | Every 90 days, or immediately on suspected compromise |
| Service tokens | Every 180 days |
| Database credentials | Every 90 days, or immediately on personnel change |
| TLS/SSL certificates | Before expiry (automated renewal preferred) |
| SSH keys | Annually, or immediately on departure or suspected compromise |
| Application secrets | Every 90 days |
| Provider-managed encryption keys | Per provider rotation schedule (verified during vendor assessment) |

### 6.5 Key Revocation on Personnel Changes

Keys and credentials for departing employees or contractors must be revoked within 24 hours of departure. This includes SSH keys, API tokens, service account credentials, and access to secrets management systems.

---

## 7. Certificate Management

- An inventory of all active TLS certificates is maintained by the DPO or designated technical lead.
- Certificate expiry is monitored. Alerts must fire at least 30 days before expiry.
- Certificate renewal or replacement is completed at least 7 days before expiry.
- Automated certificate management (e.g., Let's Encrypt auto-renewal via hosting platform) is preferred.
- Certificate-related incidents (expiry, misconfiguration, revocation) are treated as security incidents.

The certificate inventory must include: domain(s) covered, issuing Certificate Authority, expiry date, renewal method, and responsible party.

---

## 8. Backup Encryption

- All backups containing customer data or PII must be encrypted using AES-256.
- Backup encryption keys are managed separately from the backup files.
- Backup encryption is verified as part of quarterly backup restoration tests.
- Unencrypted backups must not be created, even temporarily.

---

## 9. Prohibited Algorithms and Protocols

The following are prohibited for any security use in WiBiz systems:

| Prohibited | Reason | Replacement |
|---|---|---|
| DES, 3DES | Insufficient key length, known vulnerabilities | AES-256 |
| RC4 | Known biases and practical attacks | AES-256 |
| MD5 (for signing or integrity) | Collision vulnerabilities | SHA-256 or SHA-384 |
| SHA-1 (for signing or certificates) | Collision attacks demonstrated | SHA-256 or SHA-384 |
| TLS 1.0, TLS 1.1 | Deprecated, known vulnerabilities | TLS 1.2+ |
| SSL (all versions) | Deprecated, known vulnerabilities | TLS 1.2+ |
| RSA keys below 2048 bits | Insufficient strength | RSA-2048 minimum, RSA-4096 preferred |
| ECB mode for block ciphers | Reveals data patterns | GCM or CBC with HMAC |

**Approved algorithms:** AES-128/256 (GCM or CBC with HMAC), ChaCha20-Poly1305, RSA 2048+, ECDSA P-256+, Ed25519, SHA-256/384/512, HMAC-SHA256+, PBKDF2, bcrypt, scrypt, Argon2.

**Note:** MD5 and SHA-1 are permitted only for non-security purposes such as checksums for file integrity verification where collision resistance is not required. They must not be used for digital signatures, certificate signing, password hashing, or HMAC in security contexts.

---

## 10. Cloud Service Encryption Requirements

### 10.1 Vendor Obligations

All SaaS vendors and cloud service providers used by WiBiz must:

- Encrypt data at rest using AES-256 or equivalent
- Encrypt data in transit using TLS 1.2 or higher
- Provide documentation of their encryption practices (SOC 2 report, security whitepaper, or equivalent)
- Support secure key management practices
- Notify WiBiz of any changes to their encryption posture that could affect WiBiz data

### 10.2 Vendor Assessment

Before onboarding a new vendor that will process Confidential or Restricted data:

1. Review the vendor's security documentation and certifications
2. Confirm encryption at rest and in transit meets this policy's standards
3. Confirm the vendor does not use prohibited algorithms for WiBiz data
4. Document findings in the Vendor Security Register
5. Obtain DPO approval before proceeding

### 10.3 Ongoing Monitoring

- Vendor security posture is reviewed annually
- Changes to vendor encryption practices must be communicated to the DPO
- Vendors that fail to meet encryption requirements must be remediated within 30 days or replaced

---

## 11. Email Encryption

### 11.1 Standard Business Email

All outbound email from WiBiz systems uses TLS for transport encryption (opportunistic TLS at minimum, enforced TLS where the recipient supports it). This is acceptable for Internal and Public classified communications.

### 11.2 Sensitive Communications

Email containing Confidential or Restricted data must use one of the following:

- Encrypted attachment (AES-256 encrypted ZIP or password-protected PDF, with password shared via separate channel)
- Secure file sharing link with access controls rather than direct attachment
- End-to-end encrypted email service where available

### 11.3 Prohibited Email Content

The following must never be sent via unencrypted email:

- Passwords or authentication credentials
- API keys or tokens
- Payment card numbers
- Health records or medical information
- Unredacted personal identification numbers

---

## 12. Endpoint Encryption

### 12.1 Full Disk Encryption

All company-owned and company-used devices must have full-disk encryption enabled:

| Platform | Requirement |
|---|---|
| macOS | FileVault must be enabled |
| Windows | BitLocker must be enabled with TPM |
| Linux | LUKS full disk encryption |

Devices without verified disk encryption are not permitted to access WiBiz systems.

### 12.2 Mobile Devices

Mobile devices used to access WiBiz systems or data must have:

- Device encryption enabled (enabled by default on modern iOS and Android)
- Screen lock with biometric or PIN (minimum 6 digits)
- Remote wipe capability enabled

### 12.3 Removable Media

- Use of removable media (USB drives, external hard drives) for Confidential or Restricted data is discouraged
- Where required, removable media must be encrypted (AES-256) and the use logged
- Removable media must be securely wiped before disposal or reuse

### 12.4 Verification

Encryption status is verified:

- At device provisioning (before any access to WiBiz systems is granted)
- Quarterly via device audit
- Non-compliant devices are blocked from accessing WiBiz production systems or client data

---

## 13. Compliance Mapping

This policy supports compliance with:

- **PDPA (Singapore):** Protection of personal data in transit and at rest.
- **GDPR (EU):** Article 32 — appropriate technical measures for data protection.
- **HIPAA (US):** Encryption of electronic protected health information (ePHI) where applicable.
- **PCI DSS:** Encryption of cardholder data (managed by payment processors; WiBiz does not store card data directly).

---

## 14. Exceptions

Any exception to this policy requires:

1. Written request describing the exception, its scope, and its duration
2. A risk assessment of the exception
3. Compensating controls in place
4. DPO approval (CEO approval for Restricted data)
5. A defined expiry date (maximum 6 months, renewable)

Exceptions are logged in the Policy Exception Register and reviewed quarterly.

---

## 15. Violations

Violations of this policy may result in disciplinary action up to and including termination. Unencrypted exposure of customer data is treated as a security incident and triggers the Incident Response procedure.

---

## 16. Related Documents

- WiBiz Data Protection and Privacy Policy (WBZ-SEC-001)
- Information Security Policy
- Access Control Policy
- Incident Response Policy

---

## 17. Revision History

| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | 15 April 2026 | DPO, Digital Benefits Pte Ltd | Initial release |

---

*End of document.*