Cryptography Policy

Purpose

This Policy sets how Tidewell IT uses cryptography to protect the confidentiality and integrity of information, so that encryption is strong, consistent, and manageable throughout its life.

Scope

This Policy covers every system, service, device, and process of Tidewell IT that encrypts, signs, or authenticates data, and the keys and certificates they depend on.

Policy statements

Approved algorithms

1. Only algorithms and key lengths that are recognised as strong by current industry guidance are used. Algorithms that are deprecated are phased out on a plan that the Change Manager approves.
2. Home-made cryptography is not allowed. Systems use well-reviewed, maintained libraries.
3. Passwords are stored only as salted hashes made with a slow, purpose-built hashing function.
4. The Change Manager reviews the list of approved algorithms every year, and again when a weakness is published.

Encryption in transit and at rest

1. Data in transit is protected with TLS 1.2 as the minimum. TLS 1.3 is preferred and is enabled wherever the systems on both sides support it.
2. Data at rest is encrypted with AES-256 on servers, storage, and backups.
3. Full-disk encryption is enabled on every laptop before it is handed out, and the Service Desk checks it again at every inventory.
4. Management interfaces are never reachable without encryption.
5. Backups are encrypted before they leave the system they come from, and the copy in the other data centre is encrypted as well.

Key management

1. Every key has an owner, a purpose, and a place in the key inventory.
2. Keys are rotated yearly, and at once when a key may have been exposed or when a person with access leaves.
3. Keys are stored apart from the data they protect, in a system built for key storage, and are never kept in repositories, tickets, or chat.
4. Recovery of a backup key needs two people, each holding part of the access, and every recovery is logged.
5. Changes to keys of critical systems are recorded with the names of the people who took part.

Certificates

1. The Change Manager keeps an inventory of certificates with their owner, use, and expiry date.
2. Expiry alerts go out 30 days ahead, and the owner renews the certificate before it lapses.
3. Certificates are issued by trusted authorities, and private keys of certificates are generated on the system that uses them where possible.
4. Self-signed certificates are used only inside test environments.

Roles and responsibilities

The Change Manager owns this Policy, the key inventory, and the certificate inventory. System owners apply the rules to their systems. The Service Desk Lead checks laptop encryption. The ISMS Manager reviews exceptions and reports on the state of cryptography to the Management Board.

Exceptions

An exception needs a written request to the ISMS Manager that states the reason, the risk, and an end date. Where a legacy system cannot meet the minimum protocol version, the Change Manager records a compensating control and a retirement date.

Compliance and enforcement

Breaches of this Policy lead to disciplinary measures under the HR process. Weak or expired cryptography found in a scan or an audit is raised as a Finding and tracked to closure.

Related documents

• Information Security Policy
• Information Classification and Retention Policy
• Access Control Policy
• Backup and Restore Procedure
• Vulnerability and Patch Management Procedure

Review

The Change Manager reviews this Policy at least once a year and after a significant change. The Management Board approves each revised version.