Encryption Policy

1. Overview

InContext Solutions is committed to protecting the confidentiality, integrity, and availability of sensitive data through the application of robust cryptographic controls. This Encryption Policy establishes the requirements for encrypting data at rest and in transit, defines approved cryptographic algorithms, and outlines key management procedures to ensure that encryption is applied consistently and effectively across the organization.

Encryption serves as a critical layer of defense against unauthorized access, data breaches, and interception of sensitive information. By enforcing strong encryption standards, InContext Solutions reduces the risk of data exposure and demonstrates compliance with applicable regulatory and contractual obligations.

2. Scope

This policy applies to:

• Data Classifications: All data classified as Restricted or Confidential under the Data Management Policy.

• Systems and Infrastructure: All systems, databases, applications, endpoints, and cloud services that process, store, or transmit Restricted or Confidential data.

• Transmission Channels: All network communication channels used to transmit sensitive data, including internal networks, public internet connections, email, APIs, and file transfer mechanisms.

• Personnel: All employees, contractors, and third-party service providers who handle or have access to Restricted or Confidential data.

3. Encryption Standards

Approved Algorithms

The following cryptographic algorithms and protocols are approved for use within InContext Solutions:

• Symmetric Encryption: AES-256 (Advanced Encryption Standard with 256-bit keys) for all data-at-rest encryption.

• Transport Layer Security: TLS 1.2 as the minimum required version, with TLS 1.3 preferred for all new implementations and configurations.

• Asymmetric Encryption: RSA with a minimum key length of 2048 bits, or Elliptic Curve Digital Signature Algorithm (ECDSA) with equivalent or greater strength, for digital signatures, key exchange, and certificate operations.

• Hashing: SHA-256 or stronger (SHA-384, SHA-512) for all hashing operations including integrity verification, digital signatures, and password storage mechanisms.

4. Data at Rest

All Restricted and Confidential data stored on any medium must be encrypted using approved algorithms. The following requirements apply:

• Endpoint Full Disk Encryption: All company-managed endpoints must have full disk encryption enabled. Windows devices must use BitLocker with AES-256 encryption. macOS devices must use FileVault 2. Encryption status is monitored and enforced through endpoint management solutions.

• Database Encryption: All databases containing Restricted or Confidential data must employ encryption at the storage layer. Azure SQL databases use Transparent Data Encryption (TDE) with AES-256. Additional column-level or cell-level encryption is required for highly sensitive fields such as personally identifiable information or payment data.

• Backup Encryption: All backup media and backup data streams must be encrypted using AES-256. Backup encryption keys must be stored separately from the backup data and managed in accordance with the Key Management section of this policy.

• Storage Account Encryption: All cloud storage accounts (Azure Blob Storage, Azure File Storage, and equivalent services) must have encryption enabled at the service level. Platform-managed encryption is the baseline, with customer-managed keys required for Restricted data.

• Removable Media: The use of removable media (USB drives, external hard drives, optical media) for Restricted or Confidential data is discouraged. Where business necessity requires it, all removable media must use hardware-based or software-based AES-256 encryption, and usage must be approved by the Information Security Team.

5. Data in Transit

All Restricted and Confidential data transmitted over any network must be protected using approved encryption protocols:

• Web Traffic: All web-facing applications and services must enforce HTTPS using TLS 1.2 or higher. HTTP connections must be automatically redirected to HTTPS. HTTP Strict Transport Security (HSTS) headers must be configured on all public-facing web applications.

• HTTPS Enforcement: TLS certificates must be obtained from trusted, publicly recognized Certificate Authorities. Self-signed certificates are not permitted in production environments.

• Email Encryption: Sensitive data transmitted via email must be encrypted using TLS for transport-level protection. For Restricted data, message-level encryption (such as S/MIME or Microsoft 365 Message Encryption) is required in addition to transport encryption.

• VPN Encryption: Remote access VPN connections must use IKEv2 or OpenVPN with AES-256 encryption. Split tunneling configurations must be evaluated and approved by the Information Security Team to ensure sensitive traffic is always routed through encrypted tunnels.

• API Communication: All API endpoints must require TLS 1.2 or higher. API authentication tokens and credentials must never be transmitted in plaintext. Mutual TLS (mTLS) is required for service-to-service API communication involving Restricted data.

• Internal Service-to-Service Communication: Encryption is required for all internal service-to-service communication that involves Restricted or Confidential data. Where feasible, mTLS or equivalent encryption is recommended for all internal microservice communication regardless of data classification, following a zero-trust architecture model. Refer to the Network Security Policy for additional network encryption requirements.

6. Key Management

Effective key management is essential to the strength of any encryption program. InContext Solutions maintains the following key management controls:

• Key Generation: Cryptographic keys must be generated using approved cryptographically secure random number generators (CSPRNGs). Key generation must occur within secure environments, such as hardware security modules (HSMs) or Azure Key Vault, to prevent exposure of key material during generation.

• Key Storage: Private keys and symmetric keys must never be stored in plaintext. Keys must be stored in hardware security modules (HSMs) or Azure Key Vault with appropriate access controls. Application code, configuration files, and source code repositories must never contain encryption keys or secrets.

• Key Access Controls: Access to encryption keys is restricted to authorized personnel and services on a need-to-know basis. All key access is logged and monitored. Administrative access to key management systems requires multifactor authentication and is subject to periodic access reviews.

• Key Backup and Recovery: Encryption keys must be backed up securely to enable recovery in the event of key loss or system failure. Key backups must be stored in a separate, secured location from the data they protect. Recovery procedures must be documented and tested at least annually.

• Key Destruction: When encryption keys reach the end of their lifecycle or are no longer needed, they must be securely destroyed using approved methods that render the key material unrecoverable. Key destruction events must be documented, including the date, method, responsible party, and the key identifier.

7. Certificate Management

Digital certificates are a critical component of the encryption infrastructure and must be managed throughout their lifecycle:

• Certificate Authority Requirements: Certificates for production environments must be issued by trusted, publicly recognized Certificate Authorities (CAs) or by the organization's approved internal CA for internal-only services. The use of self-signed certificates in production is prohibited.

• Certificate Lifecycle Management: All certificates must be tracked in a central inventory that includes the certificate purpose, issuing CA, expiration date, and responsible owner. Certificate requests, issuance, renewal, and revocation must follow documented procedures.

• Certificate Monitoring and Renewal: Automated monitoring must be in place to alert the responsible team at least 30 days before certificate expiration. Certificates must be renewed before expiration to prevent service disruptions. Expired certificates must be treated as a security incident.

• Wildcard Certificate Restrictions: Wildcard certificates may be used only where operationally justified and approved by the Information Security Team. The private key for wildcard certificates must be protected with the highest level of access control. Wildcard certificates must not be deployed across trust boundaries or shared with third parties.

• Certificate Pinning Considerations: Certificate pinning may be implemented for high-security applications to mitigate man-in-the-middle attacks. Where pinning is used, backup pins must be configured to prevent service outages during certificate rotation. The operational impact of pinning must be evaluated before implementation.

8. Cloud Encryption

InContext Solutions leverages Microsoft Azure as its primary cloud platform and utilizes the following encryption capabilities:

• Azure Storage Service Encryption (SSE): All Azure Storage accounts use SSE with AES-256 encryption enabled by default. Platform-managed keys are the baseline; customer-managed keys stored in Azure Key Vault are required for Restricted data.

• Azure SQL Transparent Data Encryption (TDE): All Azure SQL databases have TDE enabled to encrypt data, log files, and backups at rest. Customer-managed TDE protectors stored in Azure Key Vault are used for databases containing Restricted data.

• Azure Key Vault: Azure Key Vault serves as the primary key management service for cloud-hosted encryption keys, secrets, and certificates. Key Vault access policies enforce least-privilege access, and all operations are logged to Azure Monitor for auditing.

• Customer-Managed Keys vs. Platform-Managed Keys: Platform-managed keys provide a strong baseline for Confidential data. Customer-managed keys (CMKs) are required for Restricted data to maintain full control over the encryption key lifecycle. CMKs are stored in Azure Key Vault with soft-delete and purge protection enabled.

• Application-Layer Encryption: Where additional protection is warranted, application-layer encryption is implemented to encrypt sensitive fields before data reaches the storage layer. This provides defense in depth by ensuring data remains encrypted even if storage-level encryption is bypassed.

9. Exceptions

While encryption is mandatory for all Restricted and Confidential data, InContext Solutions recognizes that limited exceptions may be necessary in certain circumstances:

• Exception Request Process: Any request to deviate from this policy must be submitted in writing to the Information Security Team. The request must include a business justification, a description of the data and systems affected, and a risk assessment.

• Risk Acceptance: Exceptions require formal risk acceptance by the Data Owner and the Information Security Manager. The accepted risk must be documented in the organization's risk register.

• Compensating Controls: Where encryption cannot be applied, compensating controls must be documented and implemented to mitigate the risk. Compensating controls are subject to review and approval by the Information Security Team.

• Time-Limited Exceptions: All exceptions are time-limited and must include a review date no more than six months from the approval date. At the review date, the exception must be re-evaluated and either renewed with updated justification or resolved by implementing the required encryption.

10. Compliance and Enforcement

InContext Solutions enforces this policy through ongoing monitoring, auditing, and accountability measures:

• Regular Encryption Audits: The Information Security Team conducts periodic audits to verify that encryption controls are implemented and functioning as required. Audits cover data at rest, data in transit, key management practices, and certificate management.

• Vulnerability Scanning for Weak Ciphers: Automated vulnerability scanning and configuration assessments are performed to identify the use of weak or deprecated ciphers, protocols, or key lengths. Findings are prioritized and remediated in accordance with the organization's vulnerability management process.

• Non-Compliance Consequences: Failure to comply with this policy may result in disciplinary action, up to and including termination of employment or contract. Systems found in violation of encryption requirements may be isolated from the network until remediation is complete. Repeated or willful non-compliance will be escalated to senior management.

Revision History