A Security Requirements Guide, or SRG, is a prescriptive security baseline that sets mandatory configuration and hardening requirements for a system, platform or workload. It is used to standardise secure settings, reduce attack surface and support accreditation or compliance reviews across environments.
What a Security Requirements Guide actually does
A Security Requirements Guide is a prescriptive baseline, not a mere checklist. It converts security intent into mandatory configuration rules so teams can harden systems consistently, compare builds against the same standard, and document deviations in a reviewable way.
In practice, an SRG sits between a policy statement and a technical build guide. It specifies what must be enabled, disabled, constrained or documented, so security requirements are repeatable across hosts, platforms and workloads rather than left to local preference.
How SRGs relate to hardening and benchmark standards
SRGs are closely related to hardening benchmarks and configuration standards, but the important distinction is their role as an enforceable baseline. A benchmark may describe secure settings; an SRG turns those settings into an authoritative requirement set for a defined environment.
This is why SRGs are often used alongside implementation guides and audit evidence. They help teams translate broad controls into concrete settings, while still allowing exceptions, compensating controls and environment-specific tailoring where the platform cannot meet the default baseline.
Where SRGs fit in secure operations
An SRG becomes useful when many systems need the same secure posture, especially where manual review would create inconsistency. It supports build standardisation, change control, accreditation packages and repeatable assessments by giving operators a single reference point for required settings.
That standardisation also helps separate what is mandatory from what is optional. When hardening rules are written down clearly, security teams can test drift, validate exceptions and confirm that new deployments start from an approved security floor rather than an ad hoc configuration.
For application and platform teams, the practical value is that SRGs reduce ambiguity during procurement, deployment and maintenance. The requirements should be specific enough that a reviewer can verify compliance without guessing what the baseline was meant to be.
What an SRG should contain
A useful SRG names the system scope, the security objective and the required configuration outcome. It should identify the settings that matter most for attack surface reduction, such as authentication posture, remote access controls, logging, service exposure and default configuration removal.
It should also define how exceptions are handled. The baseline is strongest when it states what evidence is needed for a deviation, who approves it and whether a compensating control is required. That makes the SRG actionable in both engineering and governance workflows.
- Scope the platform, workload or system family covered by the baseline.
- State the mandatory setting or hardening action in testable language.
- Define how to verify compliance and how to record exceptions.
- Link the baseline to the review, accreditation or control objective it supports.
Risk and Threat Considerations
An SRG matters because weak or inconsistent configuration is a common way security posture degrades over time. If the baseline is missing, outdated or loosely interpreted, systems can retain exposed services, permissive defaults or insecure management paths that attackers routinely look for.
Failure mechanism: Configuration drift, incomplete hardening or unapproved exceptions can create a repeatable attack surface across many assets, making compromise easier and detection harder.
Impact: The result can be broader exposure than intended, failed accreditation evidence, or a platform that looks compliant in policy but remains vulnerable in operation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V13 — Configuration | SRGs define mandatory secure configuration baselines for systems and workloads. |
| Recommendation — Map hardening settings to V13 and verify the required configuration state before release. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | SRGs operationalise required secure settings and baseline hardening controls. |
| Recommendation — Use CM-6 to define, document and enforce approved security configuration settings. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | SRGs govern secure configuration baselines and controlled deviations across environments. |
| Recommendation — Apply A.8.9 to control baseline configuration, exceptions and configuration changes. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | SRGs are a prescriptive secure configuration baseline for systems and workloads. |
| Recommendation — Adopt CIS-4 to harden assets against insecure defaults and configuration drift. | ||
| NIST CSF 2.0 | PR.DS-02 — Data in transit is protected | SRGs often mandate baseline transport-security settings and hardening requirements. |
| Recommendation — Use PR.DS-02 to require approved protection settings for data movement and service communication. | ||
Practitioner Guidance
Governance implication: Treat the SRG as a controlled baseline with ownership, versioning and exception handling, not as an informal reference document. The baseline is only effective when someone is accountable for keeping it current as platforms, threats and assurance expectations change.
What to watch for: Watch for baselines that are too generic to test, too old to reflect current platform behaviour, or too broad to apply cleanly across different deployment patterns. Those are the versions most likely to be copied but not actually enforced.
Related resources from NHI Mgmt Group
- Guide: Security Requirements and Abuse Cases Guide
- How should security teams align identity controls with compliance requirements?
- How should security teams map cyber insurance requirements to IAM controls?
- How do security and compliance requirements shape IAM selection?
- How should security teams handle GDPR requirements in identity programmes?