Secure Configuration Baseline Standard Template (ISO/IEC 27001 A.8.9)

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.

Document control

Approvals

Revision history

Contents

• 1. Purpose and scope
• 2. Roles and responsibilities
• 3. Principles
• 4. Baseline catalogue
• 5. Common hardening requirements
• 6. Configuration as code
• 7. Drift detection and response
• 8. Change control and baseline lifecycle
• 9. Deviations and exceptions
• 10. Metrics
• 11. Size tiers
• 12. Records and evidence
• 13. References
• Standard and licence note

1. Purpose and scope

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:

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

3. Principles

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

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

6. Configuration as code

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):

{
  "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

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

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

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

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

12. Records and evidence

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

13. References

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.