# Secure Configuration Guidance Template ## Description Client-fillable template for the Secure Configuration Guide and cryptographic module documentation the provider of the offering owns, with sample text, the SCG and CMU rules and KSI-SVC statements it answers, and how the platform evidences the practice. ## Resolution # Secure Configuration Guidance Template **TEMPLATE - this document describes practices the provider of the offering owns, outside the GRCITSM platform. Replace the sample text with your organization's actual practice before publishing. The GRCITSM platform evidences these practices through scheduled validation checks; it does not execute them.** ## Purpose This template is the starting point for the Secure Configuration Guide your organization publishes for the cloud service offering, and for the cryptographic module documentation that rides with it. The Secure Configuration Guide is a product deliverable: it tells agency customers how to configure, operate, and decommission the accounts that control their tenant, and what each security-relevant setting does. Your engineering and product organizations own its content. Fill in the sample sections with what your offering actually does, then publish the guide through the channel named in the Organization-Defined Values table. ## Requirements this document answers | ID | Force | Statement | |---|---|---| | SCG-CSO-RSC | MUST | Providers MUST create, maintain, and make available recommendations for securely configuring their cloud services (the Secure Configuration Guide) that includes at least the following information: | | SCG-CSO-AUP | MUST | Providers MUST include instructions in the FedRAMP Certification Package that explain how to obtain and use the Secure Configuration Guide. | | SCG-CSO-PUB | SHOULD | Providers SHOULD make the Secure Configuration Guide available publicly. | | SCG-CSO-SDF | SHOULD | Providers SHOULD set all settings to their recommended secure defaults for top-level administrative accounts and privileged accounts when initially provisioned. | | SCG-ENH-CMP | SHOULD | Providers SHOULD offer the capability to compare all current settings for top-level administrative accounts and privileged accounts to the recommended secure defaults. | | SCG-ENH-EXP | SHOULD | Providers SHOULD offer the capability to export all security settings in a machine-readable format. | | SCG-ENH-API | SHOULD | Providers SHOULD offer the capability to view and adjust security settings via an API or similar capability. | | SCG-ENH-MRG | SHOULD | Providers SHOULD also provide the Secure Configuration Guide in a machine-readable format that can be used by customers or third-party tools to compare against current settings. | | SCG-ENH-VRH | SHOULD | Providers SHOULD provide versioning and a release history for recommended secure default settings for top-level administrative accounts and privileged accounts as they are adjusted over time. | | CMU-CSO-CMD | MUST | Providers MUST document the cryptographic modules used in each service (or groups of services that use the same modules) where cryptographic services are used to protect federal customer data, including whether these modules are validated under the NIST Cryptographic Module Validation Program or are update streams of such modules. | | CMU-CSO-UVM (Class C) | SHOULD | Providers with Class C Certifications SHOULD use cryptographic modules or update streams of cryptographic modules with active validations under the NIST Cryptographic Module Validation Program when using cryptographic services to protect federal customer data. | | CMU-CSO-CAT | SHOULD | Providers SHOULD configure agency tenants by default to use cryptographic services that use cryptographic modules or update streams of cryptographic modules with active validations under the NIST Cryptographic Module Validation Program when such modules are available. | The three items SCG-CSO-RSC requires the guide to contain, verbatim: 1. "Required: Instructions on how to securely access, configure, operate, and decommission top-level administrative accounts that control enterprise access to the entire cloud service offering." 2. "Required: Explanations of security-related settings that can be operated only by top-level administrative accounts and their security implications." 3. "Recommended: Explanations of security-related settings that can be operated only by privileged accounts and their security implications." ### Key Security Indicators in scope | KSI | Name | Statement | |---|---|---| | KSI-SVC-ACM | Automating Configuration Management | The configuration of machine-based information resources is managed using automation and persistently reviewed for drift. | | KSI-SVC-ASM | Automating Secret Management | Management, protection, and regular rotation of digital keys, certificates, and other secrets is automated and persistently reviewed. | | KSI-SVC-EIS | Evaluating and Improving Security | Information resources are persistently evaluated for opportunities to improve security and those improvements are persistently made. | | KSI-SVC-SIN | Securing Information | Information is encrypted or otherwise secured from unwanted access or modification. | | KSI-SVC-VRI | Validating Resource Integrity | Use cryptographic methods to validate the integrity of machine-based information resources. | | KSI-SVC-PRR | Preventing Residual Risk | (no statement published in the 2026 Consolidated Rules) | | KSI-SVC-RUD | Removing Unwanted Data | (no statement published in the 2026 Consolidated Rules) | | KSI-SVC-VCM | Validating Communications | (no statement published in the 2026 Consolidated Rules) | !!! note "Where KSI-SVC-ACM and KSI-SVC-EIS are documented" The GRCITSM platform's own configuration article was retired and its ports, protocols, and services content folded into the Asset, Inventory, and Assessment Scope Policy and Procedures. The SCG rule family, KSI-SVC-ACM, and KSI-SVC-EIS route to this template instead. Drift handling on the platform side stays with the Change Management Policy and Procedures; configuration-evaluation monitoring stays with the Continuous Monitoring and Reporting Policy and Procedures. ## Sample practice: the Secure Configuration Guide **Sample text.** [Organization] publishes the [Offering] Secure Configuration Guide at [guide URL]. The guide is written for the customer administrator who holds a [top-level admin role name] account and covers, per section: initial provisioning and secure access of that account, the multi-factor and recovery options available to it, each tenant-wide security setting it can operate with the security implication of each value, the settings reserved to [privileged role name] accounts, and the decommissioning sequence that revokes enterprise access and exports tenant data. Every setting entry names its secure default and states what changing it exposes. The guide is versioned as [scheme], and each release carries a dated change log entry for any adjusted default. *Replace with your practice.* Name the actual guide, its audience, its section structure, the account role names your offering uses, and how it is versioned. **Sample text.** New tenants provision with all [top-level admin role name] and [privileged role name] settings at their recommended secure defaults. Customers can compare their current settings against those defaults from [comparison surface], export the full setting set as [machine-readable format], and read or adjust settings through [API name]. A machine-readable copy of the guide is published alongside the human-readable version at [machine-readable guide URL]. *Replace with your practice.* State which of these capabilities exist. Where one does not exist, say so and explain why: the SHOULD rules accept an explanation of why the functionality is not available. **Sample text.** Instructions for obtaining and using the guide appear in the FedRAMP Certification Package at [package location], and the guide itself is public at [public URL]. [Or: the guide is provided on request to authorized agency customers through [request channel]; the decision to restrict it rests on [rationale].] *Replace with your practice.* Pick the branch that is true, and state where the obtain-and-use instructions live in the package. ## Sample practice: cryptographic modules **Sample text.** [Organization] maintains a cryptographic module inventory covering every service in the offering that uses cryptographic services to protect federal customer data. Each entry records the service or service group, the module and version, the module's status under the NIST Cryptographic Module Validation Program, and whether the deployed build is an update stream of a validated module. The inventory is reviewed [cadence] and on any change to a module or its validation status. Where a validated module is available for a cryptographic service, agency tenants are configured to use it by default; the exceptions are listed with the reason in [exception register]. *Replace with your practice.* Attach or link the actual inventory. List the exceptions honestly. Class C is a SHOULD on validated module use, so a documented exception is a legitimate answer; an undocumented gap is not. ## Sample practice: configuration automation and secret management **Sample text.** Machine-based information resources are configured through [infrastructure-as-code tooling], and the running state is compared against the declared state [cadence] by [drift tooling]. Drift is [remediated automatically / raised as a change] depending on [criteria]. Digital keys, certificates, and other secrets are held in [secret store], issued through [issuance path], and rotated [rotation cadence per secret class]; rotation success and secret age are reported [reporting cadence]. Resource integrity is validated using [signing or attestation mechanism] before deployment. *Replace with your practice.* Name the tools, the cadences, and who reviews the drift and rotation reports. ## Organization-defined values | Value | Setting | Notes | |---|---|---| | Secure Configuration Guide location | [guide URL] | SCG-CSO-RSC | | Public availability | [public / on request] | SCG-CSO-PUB, SHOULD | | Machine-readable guide location | [URL or "not available", with reason] | SCG-ENH-MRG, SHOULD | | Certification Package location of obtain-and-use instructions | [section] | SCG-CSO-AUP | | Top-level administrative account name in the offering | [role name] | Named in the guide per SCG-CSO-RSC note | | Privileged account name in the offering | [role name] | Same | | Setting comparison capability | [surface or "not available", with reason] | SCG-ENH-CMP, SHOULD | | Setting export format | [format or "not available", with reason] | SCG-ENH-EXP, SHOULD | | Settings API | [API name or "not available", with reason] | SCG-ENH-API, SHOULD | | Guide versioning scheme and release history location | [scheme, URL] | SCG-ENH-VRH, SHOULD | | Cryptographic module inventory location | [location] | CMU-CSO-CMD | | Validated-module exceptions | [list or "none"] | CMU-CSO-UVM Class C, SHOULD | | Configuration automation tooling | [tooling] | KSI-SVC-ACM | | Drift comparison cadence | [cadence] | KSI-SVC-ACM | | Secret store and rotation cadence per secret class | [store; cadences] | KSI-SVC-ASM | | Guide review cadence | [cadence] | Keeps the guide current | | Document owner | [role] | Fills the authority section | ## Evidence The GRCITSM platform does not write the Secure Configuration Guide, provision tenant defaults, or rotate your secrets. It evidences that these practices are in place and current, through the same machinery it uses for every other Key Security Indicator: scheduled machine checks against the offering and event-driven validation records. See the Continuous Monitoring and Reporting Policy and Procedures for the validation tree, the check cadences, and how validation runs roll up to KSI status. | Practice | What the platform records | |---|---| | Guide exists, is current, and is reachable | Validation runs against the guide URL and its version, with the review task in the recurring compliance task program | | Tenant secure defaults | Validation runs from scheduled configuration checks against provisioned tenant settings | | Configuration drift review (KSI-SVC-ACM) | Validation runs carrying pass and fail counts from the scheduled drift comparison | | Secret rotation (KSI-SVC-ASM) | Validation runs carrying secret age and rotation outcomes | | Cryptographic module inventory (CMU-CSO-CMD) | The inventory as a Component record, with validation runs on its review | | Security improvement (KSI-SVC-EIS) | Improvement Projects and the cadence sweep that fails a quarter with no activity | A failed check is a finding against your practice, not against the platform. Remediation runs through your own change process. ## Authority, review, and revision *Client fills.* Name the executive who issues this document, the role that owns its content, the review cadence, and the approval path for exceptions. Record the issue date and the revision history below. | Version | Date | Author | Change | |---|---|---|---| | [0.1] | [date] | [author] | Initial draft from template | ## Internal Memo Source: secure-configuration-guidance-template.md in the GRCITSM knowledge-base library (species: client-template; editor_type 1 = markdown). Downloaded from the public GRC-ITSM documentation site; body carried verbatim from the library source. Paste the Resolution section as the article body (description_markdown) in your GRCITSM instance and apply the Tags list. ## Tags - GRCITSM Template - Secure Configuration - FedRAMP Rev5 Class C - FedRAMP 20x Class C - KSI-SVC-ACM - KSI-SVC-ASM - KSI-SVC-EIS - KSI-SVC-PRR - KSI-SVC-RUD - KSI-SVC-SIN - KSI-SVC-VCM - KSI-SVC-VRI