Secure Development and Change Policy

Purpose

This Policy makes sure that the software, scripts, and configurations that Tidewell IT builds and changes are secure by design, and that every change to a production or customer system is controlled, tested, and reversible.

Scope

This Policy covers the development of our internal portals, automation, and customer tooling, and every change to production systems, networks, hosting platforms, and customer environments that we manage.

Policy statements

Scope

1. The rules for development apply to code, infrastructure definitions, and scripts, whether written by staff, contractors, or suppliers on our behalf.

Secure development life cycle

1. Security requirements are written down at the start of each development task, and risks are considered in the design.
2. Every change to code receives a peer review before it is merged. Peer review is mandatory, and nobody approves their own change.

Secure coding

1. Secrets, keys, and credentials are never kept in repositories.
2. Developers validate input, use maintained libraries, and keep dependencies up to date under the patch deadlines.
3. Third-party components are checked for known weaknesses and licence terms before they are used.

Security testing

1. Automated tests and code scans run on every change before release.
2. An external party performs a penetration test of the hosting platform and the internal portals every year. Findings are tracked to closure.
3. Fixes for weaknesses found in testing follow the patch deadlines.

Separate environments

1. Development, test, and production are kept apart, with separate accounts and access.
2. Production data is not used in test unless it is masked, and synthetic data is preferred.
3. Test systems are cleared of customer data and credentials before they are reused.

Change management

1. Changes are classified as Standard, Normal, or Emergency. Standard changes are pre-approved and repeatable. Normal changes are approved at the weekly change review that the Change Manager chairs.
2. An Emergency change is made to stop or prevent serious harm and is reviewed within 2 working days.
3. Every change has a description, a risk and impact statement, a test, and a rollback plan.

Configuration baselines

1. Systems are built from hardened baselines, and the baselines are versioned.
2. Drift from a baseline is detected automatically and is corrected or explained.

Planning of changes

1. Changes that affect customers are planned with the customer, with a notice period and a maintenance window.
2. Changes that carry a high risk are scheduled apart from each other so that a failure can be traced to its cause.

Roles and responsibilities

The Change Manager owns this Policy, chairs the weekly change review, and keeps the baselines. The Incident Coordinator approves Emergency changes together with a second approver. The Service Desk Lead informs affected customers. The ISMS Manager checks that tests and reviews take place.

Exceptions

An exception needs a written request to the ISMS Manager that states the reason, the risk, and an end date. Peer review and the rollback plan are not subject to exceptions.

Compliance and enforcement

Breaches of this Policy lead to disciplinary measures under the HR process. Changes found without a record are raised as Findings, and repeated cases are reported to the Management Board.

Related documents

• Change Management Procedure
• Vulnerability and Patch Management Procedure
• Access Control Policy
• Cryptography Policy
• Information Security Policy

Review

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