Secure Configuration Policy

1. Purpose

This policy makes sure that hardware, software, services and networks are set up in a secure, consistent and documented way, that the secure setting is kept over time, and that departures from it are controlled. Default settings are not secure enough for production use.

2. Scope

The policy applies to every configurable item that stores, processes or transmits Organisation information: servers, endpoints, mobile devices, network and security devices, databases, operating systems, applications, containers, cloud accounts and services, and infrastructure as code.

• In scope: initial build, change, drift detection and decommissioning.
• Out of scope: configuration of third-party SaaS beyond the tenant settings the Organisation can control; those are covered by the Cloud Computing Security Policy and Procedure.

3. Terms and Definitions

4. Roles and Responsibilities

5. Policy Statement

5.1 Baselines

1. A documented baseline must exist for each type of system in use. Baselines are based on recognised hardening guidance from the vendor or an industry body and are adapted to the Organisation's risks.
2. Baselines are approved by the Head of IT Operations and the information security manager, stored in version control, and reviewed every [12 months] and after significant vulnerabilities or changes in the product.
3. New systems must be built from a gold image or from infrastructure code that applies the baseline automatically. Manual builds need a checklist and a second-person check.
4. A system must not go live until a compliance scan has been run and findings of high severity are fixed or have an approved deviation.

5.2 Minimum hardening settings

5.3 Control of change and drift

• Configuration changes follow the Change Management Policy and Procedure. After an approved change, the baseline and the CMDB are updated within [5 working days].
• Automated checks compare the live configuration with the baseline at least [daily] for Tier 1 systems and [weekly] for others. Drift triggers an alert and a ticket; drift in a security setting must be corrected or approved within [3 working days].
• Administrative access to change configuration is limited to named people, uses multi-factor authentication, and is logged. Break-glass access is reviewed after use.
• Configuration data, such as device configurations and infrastructure code, is backed up and stored with version history under the Backup and Restoration Policy.

5.4 Deviations

A deviation from a baseline needs a recorded business or technical reason, a risk assessment, compensating controls, approval by the information security manager and the system owner, and an end date no later than [12 months]. Deviations are listed in the deviation register and reviewed [quarterly].

5.5 Decommissioning

• Before a system is retired its data is archived or deleted, its credentials and keys are revoked, its entries in monitoring and the CMDB are closed, and storage is wiped under the Asset Disposal Process.

5.6 Configuration compliance schedule

6. Baseline Content by Platform

Each baseline document must at least cover the items below for its platform. The platform engineer records the source guidance, the version, and each setting with its value and reason.

7. Compliance and Monitoring

The information security manager reports scan coverage, compliance percentage and open deviations each [month]. Internal audit tests a sample of systems against their baselines once a [year] and confirms that the baseline documents are current. Findings are tracked as corrective actions.

8. Measures

9. Records and Evidence

• Baseline documents with version history, kept while current plus [3 years].
• Scan results and drift tickets, kept [2 years].
• Deviation register with approvals, kept [3 years] after closure.
• Build checklists and gold image records, kept for the life of the system.

Annexure A: Configuration deviation request

10. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

11. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

12. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Patch Management Policy
• Change Management Policy and Procedure
• IT Asset Management Policy
• Access Control Policy
• Cryptography Policy
• Logging and Monitoring Policy
• Communications and Operations Security Policy