PR.PS-01: Configuration management practices are established and applied

To meet the pr.ps-01: configuration management practices are established and applied requirement, you must define, approve, and consistently enforce configuration standards across your technology stack, and prove you do it through repeatable change control and evidence. Operationalize it by scoping in-scope assets, setting baselines, controlling changes, monitoring drift, and retaining audit-ready records. ¹

Key takeaways:

• Configuration management must be both documented (standards, roles, workflows) and operating (changes controlled, drift detected).
• Auditors look for baselines + change records + monitoring tied to a defined asset scope.
• Evidence fails most often when teams have tools, but no traceability from policy to actual device/app configurations.

PR.PS-01 sits in the “Protect” function of NIST CSF 2.0 and asks for one thing: configuration management that exists in practice, not just on paper. If you are a Compliance Officer, CCO, or GRC lead, your job is to translate that into a control that engineers can run every week and that you can defend in an exam, customer audit, or board review. The operational challenge is consistency: fleets change, cloud services ship new features, admins make “quick fixes,” and third-party software updates introduce new defaults.

A workable PR.PS-01 program has three traits. First, it defines what “secure configuration” means for each asset class (endpoints, servers, network devices, cloud accounts, SaaS admin consoles, applications). Second, it gates change through approvals, testing, and rollback planning, with emergency paths that still create records. Third, it detects and corrects drift, so your “baseline” remains real over time.

This page gives requirement-level implementation guidance you can assign to owners, track in a GRC system, and evidence on a recurring cadence. ¹

Regulatory text

Requirement excerpt: “Configuration management practices are established and applied.” ¹

What the operator must do:
You need to (1) establish configuration management practices (policy, standards, roles, and procedures) and (2) apply them across in-scope technology (actual baselines, controlled changes, and ongoing verification). “Applied” is the differentiator: examiners and customers will test whether your documented standards match real system settings and whether exceptions are managed. ¹

Plain-English interpretation

PR.PS-01 means: define secure configurations for the systems you run, keep those configurations under control as systems change, and be able to show who changed what, when, why, and with what approval.

Configuration management here includes:

• Secure baseline configurations (hardened builds and standard settings)
• Change control (planned and emergency)
• Exception handling (approved deviations with compensating controls)
• Drift detection (monitoring and correction)
• Evidence (logs, tickets, reports) that ties back to your standards ¹

Who it applies to

Entity scope: Any organization operating a cybersecurity program using NIST CSF 2.0, regardless of industry. ¹

Operational scope (what to include):

• Identity and access systems that govern admin control (directory services, SSO, MFA enforcement points)
• Endpoints, servers, network devices, and security tooling infrastructure
• Cloud resources (accounts, subscriptions, IAM, networking, storage, key management)
• Business-critical applications and their production configurations
• SaaS platforms where configuration choices create security exposure (email, collaboration, ticketing, HRIS, CRM)
• High-impact third-party managed environments where you retain configuration responsibility or shared responsibility (for example, your tenant settings in SaaS)

A practical scoping rule: if the asset can create, store, transmit, or secure sensitive data, or if it can materially affect availability, it is in-scope for configuration management.

What you actually need to do (step-by-step)

1) Assign ownership and define the control boundaries

• Name a configuration management control owner (often IT Ops, SecOps, or Platform Engineering) and a GRC owner responsible for evidence quality.
• Define in-scope asset classes and environments (prod/non-prod, corporate/OT if applicable).
• Define what “configuration item” (CI) means in your environment: systems, images, templates, policies, and security-relevant settings.

Deliverable: RACI and scoped inventory view that shows which teams own which baselines.

2) Create configuration standards (baselines) by asset class

For each asset class, create a baseline standard that includes:

• Required security settings (examples: logging enabled, admin interfaces restricted, encryption enforced)
• Allowed management methods (approved tools, approved admin roles)
• Minimum monitoring/telemetry expectations
• Patch/config update expectations tied to your change process

Keep baselines implementable. Overly long standards fail because teams stop following them.

Deliverable: Configuration Standards document(s) with version control and approval.

3) Implement change control that produces traceable records

Your procedure must require that changes to in-scope configurations are:

• Requested (ticket or change record)
• Risk-reviewed (impact and security review appropriate to the change)
• Approved (named approver, time stamp)
• Tested/validated (as applicable)
• Implemented (with implementer identity)
• Documented (what changed; links to code or config diffs)
• Closed with verification and rollback notes if needed

Include an emergency change path with after-the-fact review so engineers can restore service without bypassing accountability.

Deliverable: Change management procedure + sample change tickets showing the required fields.

4) Standardize build and deployment mechanisms (reduce “snowflakes”)

Where possible:

• Use golden images, infrastructure-as-code, or configuration management tooling to make baselines repeatable.
• Restrict local admin rights and direct console changes in production.
• Ensure configuration sources of truth are versioned and access-controlled.

You are trying to reduce the gap between “we have a standard” and “we can actually enforce it.”

Deliverable: Evidence of standardized build/deploy approach (templates, repositories, configuration management policies) and access controls.

5) Monitor for configuration drift and remediate

Define how you will detect and respond to baseline deviations:

• Periodic scans/reports for endpoints, servers, cloud posture, and SaaS admin settings
• Alerting thresholds tied to severity (critical misconfigurations should page; low risk can go to backlog)
• A remediation workflow (ticket creation, owner assignment, due dates, exception path)

This is where most PR.PS-01 programs break: teams set baselines once and never verify them.

Deliverable: Drift reports, remediation tickets, and closure evidence.

6) Run exceptions as a governed process

Create an exception process that requires:

• Business justification
• Risk acceptance by an accountable leader
• Compensating controls (where possible)
• Expiration date and periodic review

Deliverable: Exception register with approvals and review history.

7) Prove operation with recurring evidence collection

Turn PR.PS-01 into a recurring control test:

• Sample changes from the last period and validate required approvals and implementation evidence
• Sample systems and verify they match baselines or have approved exceptions
• Validate drift findings were tracked to closure

If you use Daydream to manage controls, map PR.PS-01 to a policy, procedure, control owner, and a recurring evidence request schedule so evidence does not depend on individual heroics. ²

Required evidence and artifacts to retain

Keep evidence that connects standards to real systems:

Governance artifacts

• Configuration Management Policy and Change Management Procedure (approved versions)
• Roles/RACI for configuration ownership
• Baseline standards per asset class, with version history ¹

Operational evidence

• Change tickets/records with approval, implementation notes, and validation
• Emergency change records with post-implementation review
• Configuration drift reports (endpoint/server/cloud/SaaS as applicable)
• Remediation tickets and closure proof
• Exception register with approvals and expiry reviews ¹

Technical supporting evidence (examples)

• Screenshots or exports of SaaS security settings and admin role assignments
• Repo links to IaC/desired-state configurations and merge approvals
• System configuration snapshots or compliance scan outputs tied to asset inventory

Common exam/audit questions and hangups

Expect auditors to probe these areas:

1. Scope clarity: “Which systems are covered, and how do you know?”
   Hangup: an outdated CMDB or incomplete cloud/SaaS inventory.

2. Baseline specificity: “Show me the standard for this server / this cloud account.”
   Hangup: baselines exist only as generic policy language.

3. Change traceability: “Pick three recent changes and show approvals and validation.”
   Hangup: changes done in chat/CLI with no ticket, or tickets without evidence.

4. Drift detection: “How do you know configs didn’t drift after approval?”
   Hangup: no monitoring, or reports generated but not tracked to closure.

5. Exception discipline: “Why is this system out of baseline?”
   Hangup: informal exceptions, no expiry, no compensating controls.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Writing one baseline for everything.
  Fix: create short baselines per asset class. Add annexes for specialized systems.

• Mistake: Treating change management as an ITIL formality.
  Fix: require attachable proof (diffs, screenshots, test results) for security-relevant changes.

• Mistake: No emergency path, so teams bypass the process.
  Fix: define emergency changes with fast approval and mandatory after-action review.

• Mistake: Drift reports with no remediation workflow.
  Fix: require ticket creation and closure metrics in the same operational cadence.

• Mistake: Tools without evidence mapping.
  Fix: predefine what you will export each cycle (reports, ticket samples, approvals) and store it in an audit repository.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific regulator actions.

Practically, PR.PS-01 gaps create recognizable failure modes: misconfigured cloud storage, overly permissive admin roles, disabled logging, unmanaged internet exposure, and “temporary” changes that become permanent. Even without a named enforcement case, these weaknesses increase incident likelihood and make post-incident defensibility harder because you cannot show controlled operation. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Appoint control owner(s) and confirm in-scope asset classes and environments.
• Inventory where configs live today (IaC repos, SaaS consoles, endpoint tools, firewall managers).
• Draft or revise Configuration Management Policy and Change Procedure to require traceable records.
• Pick an initial baseline set for the highest-risk platforms (cloud IAM, email/SaaS admin, endpoints). ¹

Days 31–60 (implement and start producing evidence)

• Publish baselines with engineering sign-off and change control integration.
• Configure or standardize the ticket workflow fields needed for audit traceability.
• Stand up drift detection reporting for at least one asset class and route findings into tickets.
• Create the exception register and require expiry dates for new exceptions.

Days 61–90 (operate, test, and harden)

• Run a control operation cycle: sample changes, sample systems, validate approvals and baseline adherence.
• Close the loop: prove drift findings get remediated or formally excepted.
• Create recurring evidence packs (monthly/quarterly) and store them in a single audit-ready location.
• If you use Daydream, automate evidence requests and map PR.PS-01 to owners, procedures, and recurring collections so audits become retrieval, not reconstruction. ²

Frequently Asked Questions

Does PR.PS-01 require a specific tool (CMDB, IaC, SCCM, CSPM)?

No tool is mandated in the requirement text; auditors care that practices are established and applied. Pick tools that can produce consistent baselines, change records, and drift evidence you can retain. ¹

How do we handle SaaS configuration where we can’t control underlying infrastructure?

Treat your tenant settings as configuration items: admin roles, security settings, logging, and integration permissions. Baseline the settings you control, monitor for drift through exports or admin audit logs, and document exceptions. ¹

What counts as “applied” for configuration management?

“Applied” means you can show real systems conform to a defined baseline or have approved exceptions, and that changes are controlled with traceable records. A policy alone will not pass a serious review. ¹

We move fast and do frequent deployments. Will change control slow us down?

It doesn’t have to. Bake approvals and testing into your normal delivery workflow (for example, peer review and change records tied to releases) and reserve heavier review for high-risk configuration changes.

How should we treat emergency changes during incidents?

Allow them, but require documentation, time-bounded access, and a post-incident review that either reverts to baseline or updates the baseline through normal approval. Keep the emergency record with the incident record. ¹

What evidence is most persuasive in audits?

A tight chain: baseline standard → system compliance proof (scan/export) → change record(s) showing controlled updates → exception approval where needed. Auditors accept screenshots, exports, and tickets if they are dated, attributable, and repeatable. ¹

Footnotes

1. NIST CSWP 29

2. NIST CSF 1.1 to 2.0 Core Transition Changes; Source: NIST CSWP 29