# Secure Configuration Baseline Standard: [Organization name]

> Defines how [Organization name] establishes, documents, implements,
> monitors and reviews secure configurations for hardware, software,
> services and networks, using approved baselines per platform,
> configuration as code and drift detection. Supports ISO/IEC 27001:2022
> + Amd 1:2024 Annex A control A.8.9 (configuration management, new in
> 2022), with links to A.5.9, A.8.1, A.8.8, A.8.19, A.8.20 and A.8.32, and
> the guidance in ISO/IEC 27002:2022.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use it when you introduce A.8.9 for the first time (it is new in the
  2022 edition), when moving infrastructure to code, or after a
  misconfiguration incident.
- Fill first: the baseline catalogue in section 4 (one row per platform
  you actually run) and the drift response times in section 7.
- Main pitfall: adopting a full external benchmark unchanged and never
  measuring it. A smaller baseline that is enforced and monitored beats a
  long one that nobody checks. The auditor asks for the baseline, the
  evidence that systems match it, and the record of approved deviations.
- CIS Benchmarks are a common starting point. Cite them by name and
  version only, and keep your own tailoring decisions in this standard.
- Related templates: `isms/endpoint-device-byod-policy`,
  `isms/malware-protection-standard`, `isms/saas-productivity-security-baseline`,
  `isms/network-security-standard`, `ops/change-enablement-policy`,
  `ops/change-request`, `ops/cmdb-data-model`,
  `security/cloud-security-posture-review`, `security/vulnerability-management-policy`.
-->

## Document control

<!-- Guidance: This standard is the parent. Each platform baseline is a child document or a code repository with its own version, referenced in section 4. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-060 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@head-of-platform or head-of-it] |
| Approvers/reviewers | [@ciso], [@isms-manager], [@change-manager] |
| Last updated | YYYY-MM-DD |
| Effective from | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.8.9, cited only); ISO/IEC 27002:2022 |
| Next scheduled review | YYYY-MM-DD (at least annually, and each platform baseline when its source benchmark or OS version changes) |
| Baseline repository | [Repository URL or document library path] |
| Related documents | [Endpoint and BYOD policy DOC-ISMS-058], [Network security standard DOC-ISMS-063], [SaaS productivity suite security baseline DOC-ISMS-075] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Standard owner | [@head-of-platform] | [Prepared] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD |
| CISO | [@ciso] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@owner] | First issue |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. Purpose and scope](#1-purpose-and-scope)
- [2. Roles and responsibilities](#2-roles-and-responsibilities)
- [3. Principles](#3-principles)
- [4. Baseline catalogue](#4-baseline-catalogue)
- [5. Common hardening requirements](#5-common-hardening-requirements)
- [6. Configuration as code](#6-configuration-as-code)
- [7. Drift detection and response](#7-drift-detection-and-response)
- [8. Change control and baseline lifecycle](#8-change-control-and-baseline-lifecycle)
- [9. Deviations and exceptions](#9-deviations-and-exceptions)
- [10. Metrics](#10-metrics)
- [11. Size tiers](#11-size-tiers)
- [12. Records and evidence](#12-records-and-evidence)
- [13. References](#13-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: A.8.9 reaches every kind of platform, from laptops and servers to SaaS tenants and network gear, and the security settings matter most. List every platform family, including cloud control planes and SaaS, so none is left without a baseline owner. -->

This standard makes sure every system in the ISMS scope starts from an
approved secure configuration, stays in that state, and changes only
through controlled change. It covers:

| Platform family | In scope | Baseline holder |
|---|---|---|
| End-user operating systems (Windows, macOS, mobile) | Yes | IT operations |
| Server operating systems (Linux, Windows Server) | Yes | Platform engineering |
| Container images and orchestration (for example Kubernetes) | Yes | Platform engineering |
| Public cloud accounts, subscriptions and projects | Yes | Cloud engineering |
| Databases and middleware | Yes | Database administrators |
| Network and security devices (firewalls, switches, VPN) | Yes | Network team, see DOC-ISMS-063 |
| SaaS productivity suite | Yes | IT operations, see DOC-ISMS-075 |
| Other SaaS applications | Yes, security settings only | Application owner |
| OT controllers and HMI | [Yes / Out of scope] | OT engineering |

Configuration items are recorded in the asset inventory (DOC-ISMS-012)
or the configuration management database (`ops/cmdb-data-model`), with
the baseline ID each one must meet.

## 2. Roles and responsibilities

<!-- Guidance: Separate who writes a baseline, who approves it, who applies it and who monitors drift. The person who applies a deviation should not be the only one who approves it. -->

| Role | Responsibilities |
|---|---|
| Standard owner | Maintains this standard and the baseline catalogue, reports compliance |
| Baseline owner (per platform) | Writes and tailors the baseline, reviews it when the source changes, approves technical deviations |
| System owner | Ensures systems apply the baseline, requests exceptions, fixes drift |
| Change manager | Ensures baseline changes pass change enablement (`ops/change-enablement-policy`) |
| Security team | Reviews baselines for security, runs independent compliance scans |
| ISMS manager | Checks risk alignment, tracks exceptions and metrics, holds evidence |

## 3. Principles

<!-- Guidance: Keep principles few and testable. Each should be visible in at least one rule in sections 5 to 8. -->

1. **Secure by default.** New systems are built only from an approved
   image, template or code module that already applies the baseline.
2. **Least functionality.** Remove or disable services, ports, accounts,
   features and software not needed for the system's role.
3. **Documented tailoring.** Where the baseline departs from its source
   benchmark, the reason is recorded once in the baseline, not decided
   system by system.
4. **Code over clicks.** Configuration is defined in version-controlled
   code or policy wherever the platform allows.
5. **Measure continuously.** Compliance with the baseline is scanned
   automatically and reported.
6. **Controlled change.** Baseline and configuration changes follow
   change enablement and are traceable to an approved request.

## 4. Baseline catalogue

<!-- Guidance: One row per platform version you run. Name the source benchmark and profile level you started from (for example a CIS Benchmark at Level 1), and the date you last compared with it. Do not reproduce benchmark content here: the tailored settings live in the baseline document or code. -->

| Baseline ID | Platform and version | Source and profile | Tailoring summary | Owner | Last reviewed |
|---|---|---|---|---|---|
| CFG-BL-001 *(Example)* | Windows 11 Enterprise, managed laptops | CIS Microsoft Windows 11 Enterprise Benchmark, Level 1, version [x.y] | [12] settings relaxed for developer tooling, recorded in baseline | [@it-ops] | 2027-01-15 |
| CFG-BL-002 *(Example)* | macOS [current major version] | CIS Apple macOS Benchmark, Level 1, version [x.y] | Firewall stealth mode required, [4] settings managed by MDM defaults | [@it-ops] | 2027-01-15 |
| CFG-BL-003 *(Example)* | Ubuntu Linux LTS servers | CIS Ubuntu Linux Benchmark, Level 1 Server, version [x.y] | Separate partitions not required on cloud images (compensated by read-only root) | [@platform] | 2027-02-01 |
| CFG-BL-004 *(Example)* | Kubernetes clusters (managed service) | CIS Kubernetes Benchmark or the provider-specific CIS benchmark, version [x.y] | Control plane items owned by the provider, worker and workload items applied | [@platform] | 2027-02-01 |
| CFG-BL-005 *(Example)* | Public cloud accounts | CIS benchmark for the cloud provider, version [x.y] | Applied through policy as code in all accounts | [@cloud] | 2027-02-10 |
| CFG-BL-006 *(Example)* | PostgreSQL managed databases | CIS PostgreSQL Benchmark, version [x.y], plus provider guidance | Provider-managed items marked as inherited | [@dba] | 2027-03-01 |
| CFG-BL-007 *(Example)* | Firewalls and switches | Vendor hardening guide [version] | See network security standard DOC-ISMS-063 | [@network] | 2027-03-01 |
| CFG-BL-008 *(Example)* | Productivity suite tenant | DOC-ISMS-075 | See that baseline | [@it-ops] | 2027-01-20 |

Each baseline document or module contains at minimum:

1. Scope (platform, version, system roles it applies to).
2. Source benchmark name, version and profile, and the comparison date.
3. The list of tailored items with reason and compensating control.
4. How it is applied (image, MDM profile, code module, policy).
5. How compliance is measured (scanner, policy engine, query).
6. Owner, version and approval.

## 5. Common hardening requirements

<!-- Guidance: These apply to every platform whatever its benchmark says. They catch the issues behind most configuration findings: default credentials, open management interfaces, missing logging. -->

| Area | Requirement |
|---|---|
| Default accounts and credentials | Change or disable before the system goes live. No default passwords anywhere |
| Administrative access | Named accounts only, MFA, through approved access paths (`security/privileged-access-standard`) |
| Services and ports | Only those required for the system role are enabled, documented in the baseline |
| Management interfaces | Not exposed to the internet. Reachable only from management networks or through a bastion or identity-aware proxy |
| Time synchronisation | All systems synchronised to approved time sources (supports logging, A.8.17) |
| Logging | Security events forwarded to central logging per `security/security-logging-standard` |
| Encryption | Encryption in transit and at rest as set in `security/cryptography-standard` |
| Secrets | No secrets in images, code or configuration files (`security/secrets-management-standard`) |
| Software | Supported versions only, installed from approved sources (A.8.19) |
| Cloud storage | Public access blocked by default at account level, exceptions recorded |
| Banners and metadata | Remove version banners where the platform allows |

## 6. Configuration as code

<!-- Guidance: Describe the pipeline so an auditor can follow one change from commit to production. Peer review and automated policy checks are the evidence that A.8.9 and A.8.32 operate together. -->

```mermaid
flowchart LR
  A["Engineer commits configuration change"] --> B["Peer review in pull request"]
  B --> C["Automated checks: lint, policy as code, baseline scan"]
  C -->|Fail| A
  C -->|Pass| D["Change approved per change enablement"]
  D --> E["Pipeline applies to target environment"]
  E --> F["Post-deploy compliance scan"]
  F --> G["Results stored as evidence"]
```

Rules:

1. Infrastructure, cloud policies, images and endpoint profiles are
   defined in version-controlled repositories where the platform allows.
2. The main branch is protected. Changes need at least [one] reviewer who
   is not the author.
3. Policy-as-code checks block merges that break a baseline rule, unless
   an approved deviation is referenced in the change.
4. Golden images are rebuilt at least [monthly] to include patches and
   are signed or tagged with the baseline version they meet.
5. Manual console changes in production are allowed only during an
   incident or approved emergency change, and are written back to code
   within [2] business days.

Example baseline metadata record kept with each module *(Example)*:

```json
{
  "baselineId": "CFG-BL-003",
  "platform": "Ubuntu Linux LTS server",
  "source": "CIS Ubuntu Linux Benchmark, Level 1 Server",
  "sourceVersion": "[x.y]",
  "baselineVersion": "2.1",
  "approvedBy": "[@platform-lead]",
  "approvedOn": "2027-02-01",
  "tailoredItems": 9,
  "deviations": ["DEV-CFG-004"],
  "scanner": "[configuration scanner]",
  "scanFrequency": "daily"
}
```

## 7. Drift detection and response

<!-- Guidance: Drift is any difference between the live state and the baseline. Decide which drift is auto-corrected and which only alerts, because auto-correction can break production. -->

| Platform | Detection method *(Example)* | Frequency | Auto-remediate |
|---|---|---|---|
| Endpoints | MDM compliance policy and configuration profiles | Continuous, report daily | Yes, profiles re-applied |
| Servers | Configuration scanner or agent against CFG-BL-003 | Daily | Yes for low-risk items, alert for others |
| Cloud accounts | Cloud security posture management against CFG-BL-005 | Continuous | Preventive guardrails block, detective rules alert |
| Containers and Kubernetes | Admission policy and runtime scanner | Continuous | Admission blocks non-compliant workloads |
| Network devices | Configuration backup with diff against approved version | Daily | No, alert to network team |

| Drift severity | Example | Fix within *(Example)* |
|---|---|---|
| Critical | Storage bucket with restricted data made public, management port open to the internet | 4 hours, raise incident |
| High | Logging disabled, MFA requirement removed for admins | 2 business days |
| Medium | Non-required service enabled, weak cipher allowed internally | 10 business days |
| Low | Banner or cosmetic setting | Next scheduled change |

```mermaid
flowchart TD
  A["Scan detects drift"] --> B{"Approved deviation exists?"}
  B -->|Yes| C["Mark as accepted, no action"]
  B -->|No| D{"Severity Critical?"}
  D -->|Yes| E["Raise incident, fix within 4 hours"]
  D -->|No| F["Ticket to system owner with deadline"]
  F --> G{"Fixed by deadline?"}
  G -->|Yes| H["Close after rescan"]
  G -->|No| I["Escalate to ISMS manager"]
```

Drift found in cloud accounts is cross-checked during the periodic
cloud posture review (`security/cloud-security-posture-review`).

## 8. Change control and baseline lifecycle

<!-- Guidance: A baseline is a controlled document. Show its states and who moves it between them, and keep superseded versions so you can show what was required at the time of an incident. -->

```mermaid
stateDiagram-v2
  [*] --> Draft
  Draft --> Review: owner submits
  Review --> Draft: changes requested
  Review --> Approved: security and owner sign off
  Approved --> Published: change implemented and scans updated
  Published --> Draft: source benchmark or platform changes
  Published --> Superseded: new version published
  Superseded --> [*]
```

1. A baseline changes when the source benchmark issues a new version,
   the platform version changes, a vulnerability or incident shows a
   gap, or a business need requires a different setting.
2. Each baseline change is raised as a change request (`ops/change-request`)
   classified per `ops/change-enablement-policy`, tested in a
   non-production environment and rolled out in stages.
3. When a new benchmark version appears, the baseline owner compares it
   within [90] days and records which new items are adopted, tailored or
   rejected.
4. Superseded baselines are kept for [3] years.

## 9. Deviations and exceptions

<!-- Guidance: Distinguish tailoring (applies to everyone on the platform, recorded in the baseline) from a deviation (applies to named systems, has an expiry). Auditors sample both. -->

| Type | Scope | Approved by | Duration |
|---|---|---|---|
| Tailoring | Whole platform baseline | Baseline owner and security team | Until next baseline review |
| Deviation | Named systems | System owner requests; approved at the DOC-ISMS-010 authority for the residual risk: risk owner (Low), risk owner and department head (Medium; top management if the category is Averse), top management with a treatment decision (High). Critical residual risk is not approved as a deviation. The ISMS manager reviews and registers each one | Maximum 12 months for Low or Medium, 6 months for High; reassessed at expiry |

| Deviation ID | Baseline and item | Systems | Reason | Compensating control | Expiry |
|---|---|---|---|---|---|
| DEV-CFG-004 *(Example)* | CFG-BL-003, legacy TLS version allowed | 2 integration servers for a hospital interface | Partner system cannot upgrade until Q3 2027 | Restricted to partner IP range, monitored, partner upgrade tracked | 2027-09-30 |

Deviations are requested with the security exception request
(DOC-ISMS-122) and appear on the risk register (DOC-ISMS-016) when they
leave a residual risk above Low.

## 10. Metrics

<!-- Guidance: Report compliance per baseline, not one average, so a weak platform cannot hide behind a strong one. -->

| Metric | Formula | Target *(Example)* |
|---|---|---|
| Baseline coverage | Configuration items with an assigned baseline / all in-scope items | 100% |
| Baseline compliance | Passed checks / applicable checks, per baseline | At least 95% |
| Critical drift fixed on time | Critical drift fixed within 4 hours / all critical drift | 100% |
| Baselines reviewed on time | Baselines reviewed within 12 months / all baselines | 100% |
| Open deviations past expiry | Count | 0 |

Worked example for Quillmere Analytics Ltd *(Example)*: CFG-BL-003 has
150 applicable checks on each of 20 Linux virtual machines, 3,000 checks in total. The
scanner reports 2,880 passes, so compliance is 2,880 / 3,000 = 96.0%,
above the 95% target. The 120 failures are 90 covered by approved
deviations and 30 open drift items with tickets (90 + 30 = 120).

## 11. Size tiers

<!-- Guidance: Small organizations can meet A.8.9 with MDM profiles, the cloud provider's posture tool and a short baseline per platform. Large ones need ownership per platform and site. -->

| Aspect | Small: Quillmere Analytics Ltd | Medium: Quillmere Health Systems | Large: Quillmere Group |
|---|---|---|---|
| Platforms *(Example)* | Laptops, one cloud provider (two regions), containers, productivity suite | Laptops, servers in colocation suite, cloud, clinical integration servers | IT across 6 sites, data centre, OT in 3 plants |
| Baselines | 5 baselines, all as code or MDM profiles | 8 baselines including colocation servers and network devices | Group baselines plus site variants, OT baselines owned by plant engineering |
| Drift detection | Cloud provider posture tool, MDM compliance | Configuration scanner, posture management, MDM | Central scanner, posture management, OT-specific monitoring |
| Ownership | Head of Engineering Operations owns all baselines | Platform and IT leads per baseline, security team reviews | Group platform owners, site IT leads apply, CISO office reviews |
| Review cadence | Annual and on benchmark change | Annual and on benchmark change | Annual group review, site attestation each half year |

## 12. Records and evidence

<!-- Guidance: The strongest evidence is a scheduled compliance report per baseline plus the change history in the repository. -->

| Record | Owner | Location | Retention *(Example)* |
|---|---|---|---|
| Approved baselines, current and superseded | Baseline owners | Baseline repository | 3 years after supersession |
| Compliance scan reports per baseline | Security team | Scanner and ISMS evidence folder | 3 years |
| Pull requests and change records for configuration changes | System owners | Code repository, change system | 3 years |
| Drift tickets and incident records | System owners, security team | Ticketing system | 3 years |
| Deviation and tailoring approvals | ISMS manager | Exception register | Expiry plus 3 years |
| Benchmark comparison notes | Baseline owners | Baseline repository | 3 years |

Map each record to A.8.9 in the control evidence matrix (DOC-ISMS-033,
`isms/control-evidence-matrix`).

## 13. References

<!-- Guidance: Record the version of each source benchmark in section 4, not here. Here list the frameworks the standard follows. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024, https://www.iso.org/standard/82875.html | Current, Amd 1 https://www.iso.org/standard/88435.html | Annex A control A.8.9 and related controls |
| ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html | Current | Control guidance |
| CIS Benchmarks (Center for Internet Security) | Per platform, version recorded in section 4 | Source baselines, cited by name and version only |
| CIS Critical Security Controls v8.1 | June 2024 | Control 4 (secure configuration of enterprise assets and software), cited by number and name only |
| NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems | August 2011, updated October 2019 | Configuration management process concepts (free public source) |

Related templates: `isms/endpoint-device-byod-policy` (DOC-ISMS-058),
`isms/malware-protection-standard` (DOC-ISMS-059),
`isms/network-security-standard` (DOC-ISMS-063),
`isms/saas-productivity-security-baseline` (DOC-ISMS-075),
`compliance/asset-inventory` (DOC-ISMS-012), `ops/cmdb-data-model`,
`ops/change-enablement-policy`, `ops/change-request`,
`security/cloud-security-posture-review`, `security/privileged-access-standard`,
`security/security-logging-standard`, `security/secrets-management-standard`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A control
A.8.9 and related controls) and ISO/IEC 27002:2022. Control numbers are
cited with short original labels. All requirements, tables and examples
are original and reproduce no text from ISO/IEC standards or CIS
Benchmarks: obtain the official standards from ISO
(https://www.iso.org/standard/82875.html, https://www.iso.org/standard/75652.html)
or your national standards body, and the benchmarks from the Center for
Internet Security under its own terms. NIST SP 800-128 is a US
government publication. Check for the current edition of each reference
before use.

Template licence: MIT.