Secure Configuration Guidance¶

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.

Download the KB article (Markdown)

Requirements this document answers¶

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¶

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¶

Evidence¶

The GRC-ITSM 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.

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.