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

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

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

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:

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:

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

End of document.