OS Hardening · Evidence Helper · ISO and SOC Certifications

System Configuration Standards

Writing and maintaining hardening documentation that survives an audit. Updated: September 30, 2026.

A configuration standard is the document that says how a type of system is built and hardened in your organisation. OS installation and hardening covers doing the work; this page is about the documents, which is a separate discipline and the one engineering teams neglect — usually because the hardening genuinely exists and nobody saw the point of writing it down.

The point becomes apparent the first time an auditor, a customer's security questionnaire or a new hire asks what your standard is. All three are answered by the same artefact, and none of them is answered by a well-configured server.

1. What a Standard Is, and What It Is Not

It is a statement of intent for a type of system: what is installed, what is disabled, how access works, how it logs, and why. It is not a runbook, not an inventory, and not a record of how one particular machine happens to be configured today.

The distinction that matters most: a standard describes the target state, and something separate demonstrates that real systems match it. Conflating the two produces documents that describe reality at the moment they were written and drift into fiction afterwards.

2. Coverage Comes Before Content

The first question is not what goes in a standard. It is how many standards you need, and the answer comes from the asset inventory rather than from a template.

Build this table before writing anything. It is also, in most audits, the single artefact that answers most of the request — and building it yourself means you find the empty rows before somebody else does. The infrastructure audit normally supplies the left-hand column.

Two details on that table earn their place. An overdue review is worth showing rather than hiding, because an auditor will find the date anyway and an acknowledged gap is a lesser finding than a concealed one. And an explicit “none in estate” line is worth writing for system types you do not have: a silent absence reads as an oversight, a stated one reads as a decision.

How granular?

One document per operating system is too coarse; one per server is unmaintainable. The arrangement that works is a common base plus role addenda:

• A base standard covering what every host shares — accounts, elevation, logging, time synchronisation, patching, minimal install, backup agent.
• A short addendum per role covering only what differs: TLS configuration and disabled modules for a web server; authentication method, network binding and privileged roles for a database; and so on.

This is less work than it sounds and much easier to defend, because the shared controls are stated once and cannot drift apart between documents.

3. Derive From a Recognised Source, Then Tailor

There is no reason to invent hardening requirements. CIS Benchmarks, vendor hardening guides and DISA STIGs cover the ground far more thoroughly than anyone does from memory. Name the source and its version in your document.

What matters is that you tailored it. Attaching a benchmark PDF unchanged is a recognisable non-answer: it asserts a standard nobody has read against a system nobody has checked. Go through it, decide per item, and record the decision. “Not applicable — we do not run this service” is a perfectly good entry, and a document full of them is more credible than one that silently claims full conformance.

4. Generate the Document From the Code

For most engineering teams the hardening already exists as an Ansible role, a Packer template, a Dockerfile or a Terraform module. That code is the standard. The right move is to write the document from it — what the role enforces, why each item is there, and which values are parameterised — rather than alongside it.

Writing them independently produces two sources of truth that disagree within a quarter, and the disagreement is worse than having no document at all: an auditor who samples a running host and compares it against the standard turns a documentation gap into a control failure. A missing document is a finding about paperwork. A document contradicted by the system is a finding about your controls.

A practical arrangement: keep the standards as Markdown in the same repository as the configuration code. The commit history is your version control, pull request approvals are the approval record, and the document sits next to what implements it, so changing one without the other is visible in review. See infrastructure as code.

5. What Each Document Needs

Independently of content, a standard is only usable as evidence if it is a controlled document:

• An owner — a named person, not a team.
• A version and an effective date.
• An approval record — who approved it and when.
• A review cycle, and evidence of a review having happened inside it. Annual is the usual commitment; whatever you state, meet it.
• The source it derives from, with version.
• Its scope — which systems it governs, so the coverage table can be reconciled against it.

6. Deviations Are Normal — Record Them

Every real estate has systems that cannot meet the standard: a legacy application requiring an old TLS version, an appliance whose vendor forbids changes, a host that needs a service the baseline disables. None of that is a problem in itself. An undocumented deviation is.

Keep a deviation register: the system, what departs from the standard, why, what compensates for it, who approved it, and when it will be revisited. A standard with a register of twelve approved exceptions is a working control. A standard with no exceptions, applied to an estate that plainly contains some, tells an auditor the document is not being used.

7. Keeping Them True

Documents decay faster than systems. Three things keep them honest:

• Change them with the code. If a pull request alters the hardening role, the same pull request updates the standard. Enforced in review, this costs nothing.
• Detect drift. Re-running configuration management in check mode, or periodic benchmark scanning, produces the evidence that systems still match the standard — which is the other half that the document itself cannot supply.
• Review on the cycle, and record it. Even a review that changes nothing needs a dated entry, because “still current” is a finding only if nobody wrote it down.

Which Frameworks Ask For This

• SOC 2 — under the security common criteria, as baseline configurations for system components. The evidence request is decoded in our evidence helper.
• ISO/IEC 27001 — configuration management is one of the eleven controls added in the 2022 edition, so this is newly explicit rather than newly expected.
• PCI DSS — the most prescriptive of the three, and the origin of the phrase “system configuration standards”. If a request uses that wording and mentions POS systems, it is probably PCI vocabulary, which is worth confirming because the expectations are stricter than SOC 2's.

The useful consequence: one set of standards, built once and kept current, answers all three. This is the part of compliance work that genuinely pays for itself, because it is also how you stop building servers by hand.

What You Get

• A coverage table reconciled against the asset inventory, with the gaps named.
• A base standard plus role addenda, derived from a recognised source with the tailoring decisions recorded.
• Documents generated from the configuration code, in the repository beside it.
• A deviation register with owners, justifications and review dates.
• Drift detection producing the evidence that systems still match.

Written from an infrastructure perspective. We are not a certification body, an audit firm or a QSA, and this is not legal or assurance advice. Which requirements apply to you, and how they are interpreted, is a question for your auditor or assessor.