Secure configuration baselines and hardening discipline
Primary statement
Secure configuration baselines shall be documented for each platform class — operating system, database, application server, web server, network device, cloud service. Configurations shall be assessed against the baseline at least quarterly; deviations shall trigger remediation or documented exception. Baselines reference industry standards (CIS Benchmarks, vendor security best practices, NIST baselines) and are tailored to the organisation's threat model. The hardening discipline is the foundation of vulnerability management — most exploitable vulnerabilities are configuration-related, not patch-related.
Audit-fatigue payoff
A single configuration baselines library — per platform class, documented, maintained current, with quarterly assessment evidence — satisfies hardening requirements across PCI DSS, RBI CSF, ISO 27001, SOC 2, CIS Controls. The auditor's test reduces to: inspect the baselines, sample 3 systems against baseline, inspect quarterly assessment results, verify exception documentation. One library + one assessment process answers every framework's hardening question.
Strictness matrix
Scope
Hardening baselines per platform class: each operating system, database, application server, and network-device platform. RBI CSF PR.9 specifies four platform classes explicitly. Practical scope expansion: cloud services (per PCI DSS 2.2.1 "all system components in scope") + containers + orchestration platforms.
Ceiling source: rbi_csf:RBI.PR.9
Rationale: RBI CSF PR.9 enumerates platform classes explicitly. PCI DSS 2.2.1 specifies "all system components in scope" — broader formulation. The combined scope (per platform class + all in-scope components) is the audit-defensible baseline.
Threshold
Threshold for baseline application: ALL system components in scope. No system class is exempt without documented exception. Configuration standards shall address KNOWN SECURITY VULNERABILITIES — the threshold is not a generic baseline but a vulnerability-informed baseline.
Ceiling source: pci_dss:PCI.2.2.1
Rationale: PCI DSS 2.2.1 sets the strictest threshold: ALL in-scope components, with vulnerability-informed baselines. The "known security vulnerabilities" qualifier is the audit-defensible test.
Method
Method: (1) configuration standards developed, maintained, and applied to all system components; (2) standards reference industry best practices (CIS Benchmarks, NIST SP 800-53, vendor guidance) consistent with the organisation's threat model; (3) standards address known security vulnerabilities; (4) baseline applied on system provisioning + verified at periodic intervals + re-verified after any material change.
Ceiling source: pci_dss:PCI.2.2.1
Rationale: PCI DSS 2.2.1 specifies the most prescriptive method — standards must be developed, maintained, applied, AND vulnerability-informed. RBI PR.9 quarterly assessment cadence layers on top.
Frequency
Assessment cadence: AT LEAST QUARTERLY per RBI CSF PR.9. Re-verification after any material change. Baseline refresh on a defined cycle (annual minimum) and on new industry advisory (CIS Benchmark update, vendor advisory, CERT-In KEV affecting the platform class).
Ceiling source: rbi_csf:RBI.PR.9
Rationale: RBI CSF PR.9 quarterly cadence is the strictest periodic assessment. Other frameworks require "periodic" without specifying cadence; the quarterly minimum is the audit-defensible reference.
Evidence
Required evidence: (1) baseline document per platform class (OS baseline, DB baseline, app server baseline, network-device baseline, cloud baseline); (2) reference to the industry standard underlying each baseline (CIS Benchmark version, NIST baseline reference); (3) quarterly configuration assessment reports per platform class; (4) deviation register with remediation tracking; (5) documented exceptions with risk acceptance; (6) baseline refresh history showing updates in response to new advisories.
Ceiling source: rbi_csf:RBI.PR.9
Rationale: RBI CSF PR.9 evidence list combines baseline library + assessment cadence + deviation tracking. PCI DSS 2.2.1 evidence is similar; the combined specification is the audit-defensible evidence pack.
Auditor test pattern
Step 1: Inspect the baseline library; verify coverage of all platform classes operated by the organisation. Step 2: Sample 1 baseline (e.g., Linux server) and verify it references a current industry standard (CIS Benchmark v9+ typically). Step 3: Inspect the most recent quarterly assessment results; verify coverage matches the platform inventory. Step 4: Sample 3 systems from the assessment results and verify the actual configuration against the baseline (live spot-check). Step 5: Inspect the deviation register; verify deviations are either remediated or documented as risk-accepted exceptions with current sign-off. Step 6: Verify baseline refresh discipline — when was the OS baseline last updated against the current CIS Benchmark version?
Common findings
Common 2024–26 findings: (1) Baselines exist for OS but not for application servers, network devices, or cloud services; (2) Baselines reference an old CIS Benchmark version and have not been refreshed; (3) Quarterly assessments are scan-only without manual verification of high-risk settings; (4) Deviations remain "to be remediated" indefinitely with no exception documentation; (5) Cloud-service configurations (S3 buckets, IAM policies, security groups) not in the hardening programme — assumed to be vendor responsibility; (6) Container / Kubernetes hardening absent — modern platforms not covered; (7) New systems provisioned without baseline applied; baseline retrofitted later in non-production cycle.