Category: Configuration & Endpoint Security

Security Requirements Guide

Also known as: SRG, Security Requirements Guide (SRG), Cloud Computing Security Requirements Guide (CC SRG)

Simply put

A Security Requirements Guide (SRG) is a Department of Defense (DoD) document that lays out the security requirements applicable to a particular category of technology, such as operating systems or cloud computing services. It serves as a foundational, technology-general set of requirements from which more specific implementation guidance is later derived. SRGs are published as tools to help improve the security of DoD information systems.

Formal definition

An SRG is a DoD-published set of security requirements organized at a technology-family or capability level (for example, general-purpose operating systems or cloud computing). According to NIST's glossary, an SRG generally contains all requirements flagged as applicable from the parent level, regardless of whether they are selected on a specific DoD baseline. SRGs are typically the intermediate layer between broader security controls and product-specific Security Technical Implementation Guides (STIGs), which provide the detailed, product-tailored implementation requirements derived from an applicable SRG. A notable specialized example is the Cloud Computing Security Requirements Guide (CC SRG), which outlines the security model for DoD's use of cloud computing and supports a standardized assessment and authorization process for cloud service providers. Practitioners should verify the current revision and applicability of any given SRG against the official DoD sources, as content and structure evolve across versions and this entry does not address specific implementation, contractual, or authorization details.

Why it matters

Security Requirements Guides sit at a critical point in the DoD's layered approach to system hardening. Because they define security requirements at a technology-family level, such as general-purpose operating systems or cloud computing, they establish the common baseline from which product-specific Security Technical Implementation Guides (STIGs) are derived. For compliance officers and information system security managers, understanding the SRG-to-STIG relationship matters because implementation guidance you apply to a specific product traces back to the requirements set out in its applicable SRG. Misunderstanding that lineage can lead teams to treat STIG compliance as self-contained rather than as an implementation of a broader requirement set.

The Cloud Computing Security Requirements Guide (CC SRG) is a particularly consequential specialized example, as it outlines the security model for DoD's use of cloud computing and supports a standardized assessment and authorization process for cloud service providers. Practitioners working with cloud offerings should note an expert distinction here: participation in that DoD-oriented process is not automatically the same as, nor a substitute for, other authorizations a provider may hold. A FedRAMP authorization, for instance, does not by itself satisfy DoD requirements, and readers should confirm the specific authorization pathway and impact level applicable to their use case against current official DoD sources.

A further common mistake this guidance helps correct is conflating assessment with authorization and treating compliance as a static, one-time achievement. SRGs and their derived STIGs are tools to improve system security, but applying them does not by itself confer an Authority to Operate, which remains time-bound and subject to continuous monitoring. Because SRG content and structure evolve across revisions, relying on an outdated version can quietly undermine an otherwise sound compliance posture.

Who it's relevant to

Information System Security Managers and Engineers

Personnel responsible for hardening DoD information systems use SRGs to understand the technology-general requirements that underlie the product-specific STIGs they apply. Because SRG content evolves across revisions, they should verify the current applicable version against official DoD sources before mapping requirements to a given system.

Cloud Service Providers Serving DoD

CSPs seeking to offer services to DoD should understand the Cloud Computing Security Requirements Guide, which outlines the security model for DoD's use of cloud computing and supports a standardized assessment and authorization process. Providers should confirm the specific impact level and authorization pathway applicable to their offering and should not assume other authorizations automatically satisfy DoD requirements.

Compliance Officers and Auditors

Those assessing DoD systems benefit from tracing implementation evidence back through the STIG-to-SRG lineage to confirm that product-level controls implement the broader technology-family requirements. They should also distinguish assessment activities from authorization decisions and treat any Authority to Operate as time-bound and subject to continuous monitoring.

Authorizing Officials

AOs weighing risk for DoD systems and cloud services rely on the SRG layer as part of the foundation for authorization decisions. They should confirm the applicable SRG revision and, for cloud, the relevant authorization process, keeping in mind that compliance with derived requirements supports but does not automatically equate to a security or authorization determination.

Inside SRG

General Security Requirements

An SRG translates policy, higher-level guidance, and applicable control baselines into a collection of general, technology-class security requirements. In most implementations these requirements are not yet product-specific and serve as the source from which more detailed, product-specific guidance is derived.

Technology or Product Class Scope

Each SRG is generally organized around a category of technology or capability (for example, an operating system class, application class, or network device class) rather than a single named product, defining the security expectations common to that class.

Basis for Security Technical Implementation Guides (STIGs)

In DoD practice, an SRG typically provides the foundational, non-product-specific requirements that are then refined into product-specific STIGs. The SRG establishes the 'what,' while a STIG addresses the 'how' for a particular product; verify the current relationship in the applicable DISA guidance.

Traceability to Controls and Policy

SRG requirements are generally mapped or traceable back to applicable control sets and governing policy so that implementers can connect a specific requirement to its authoritative source. Confirm the specific control mappings against the current published version.

Governing Authority and Maintenance

SRGs in the DoD context are generally developed and maintained under Defense Information Systems Agency (DISA) processes on behalf of the DoD. The specific issuing office and revision status should be verified against current official DISA sources, as content changes across revisions.

Common questions

Answers to the questions practitioners most commonly ask about SRG.

Is a Security Requirements Guide (SRG) the same thing as a Security Technical Implementation Guide (STIG)?

No. An SRG and a STIG are related but distinct. An SRG generally provides technology-class or product-category security requirements derived from higher-level policy and control sources, stated in a technology-agnostic way. A STIG typically translates applicable SRG requirements into product-specific configuration guidance for a particular vendor product or version. In most implementations the SRG defines the 'what' at a category level while the STIG addresses the 'how' for a specific technology. Readers should confirm the current relationship and applicability against the authoritative source that maintains these documents.

Does following an SRG by itself mean a system is compliant or authorized to operate?

Not by itself. Applying SRG requirements is a configuration and security-hardening activity, not an authorization. Compliance with an SRG does not equate to security in a comprehensive sense, and it does not constitute an Authority to Operate (ATO). Authorization is a separate risk-based decision made by the responsible authorizing official, and any resulting ATO is time-bound and subject to continuous monitoring. An SRG is one input among many; assessment and authorization remain distinct processes that must be completed separately.

How does an SRG relate to a control baseline when I am building a system security package?

In most implementations an SRG is used to help translate applicable security control requirements into technology-category-level requirements that can then be operationalized. It generally supports, rather than replaces, the tailored control baseline established for the system. Practitioners typically map SRG requirements back to the governing controls and document that mapping in their system security package. Confirm the specific mapping expectations against the current authoritative guidance and any agency-specific tailoring that applies to your system.

What should I do when an SRG requirement applies but no corresponding product-specific STIG exists for my technology?

When a specific STIG is not available for a given product, the applicable SRG generally serves as the governing requirement source, and practitioners typically implement and document how each relevant SRG requirement is satisfied for that technology. This commonly involves recording the implementation approach and any compensating measures, then having them reviewed as part of the assessment process. Verify the expected handling of STIG gaps against the current authoritative guidance and coordinate with your assessor and authorizing official.

How do I handle SRG requirements that cannot be fully met in my environment?

SRG requirements that cannot be fully implemented are generally documented, with the rationale, residual risk, and any compensating or mitigating measures recorded for review. In most implementations this documentation feeds the risk-based decision made by the authorizing official rather than being resolved solely at the technical level. Because handling of deviations can be subject to agency-specific interpretation, confirm the current process and documentation expectations against the applicable authoritative source.

How should I keep pace with revisions to an SRG over time?

SRG content can change across revisions, so implementations should be validated against the applicable revision rather than assumed to be current indefinitely. As of the applicable revision, requirements, categories, and referenced sources may differ, and continuous monitoring activities generally include tracking updates and reassessing affected configurations. Readers should verify the current version and effective requirements against the official maintaining source before relying on any particular requirement.

Common misconceptions

An SRG and a STIG are the same thing and can be used interchangeably.

They are distinct. An SRG generally states general, technology-class security requirements, while a STIG provides product-specific implementation guidance derived from an SRG. Treating them as interchangeable can lead to applying non-product-specific requirements as if they were configuration steps, or vice versa.

Complying with the applicable SRG means the system is secure and authorized to operate.

Compliance with an SRG is not the same as security, and it is not an authorization. SRG conformance is one input to a broader assessment and authorization process; an Authority to Operate (ATO) is a separate, time-bound decision subject to continuous monitoring. Verify authorization requirements against the applicable RMF and agency guidance.

SRG requirements are fixed and apply identically across all systems and revisions.

SRG content evolves across revisions and may be subject to tailoring based on the technology class and applicable baselines. Practitioners should confirm they are using the current published version and understand how it applies to their specific environment.

Best practices

Confirm you are referencing the current published version of the applicable SRG against official DISA sources, since content changes across revisions.

Identify the correct technology or product class that your SRG applies to, and locate the corresponding product-specific STIG where one exists before treating requirements as implementation steps.

Trace SRG requirements back to their governing controls and policy so you can document the authoritative basis for each requirement during assessment.

Do not treat SRG or STIG compliance as equivalent to an authorization decision; feed conformance evidence into the broader assessment and authorization process and maintain it under continuous monitoring.

Document any tailoring applied to SRG requirements for your specific technology class and environment, and confirm that tailoring aligns with applicable baselines and agency guidance.

Verify product-specific configuration details in the applicable STIG rather than inferring them from the more general SRG requirements.