PL-7: Concept of Operations

Quick-reference card

What PL-07 requires

PL-07 requires organizations to develop and maintain a concept of operations (CONOPS) describing how they’ll run a system securely and with privacy protections. This isn’t a checkbox exercise. The CONOPS forces your team to articulate, in practical terms, how security and privacy objectives translate into day-to-day system operations.

That operational narrative needs to stay current. PL-07 also requires you to review and update the CONOPS at a defined frequency, ensuring it reflects the actual state of controls, architecture, and procedures rather than an outdated snapshot from initial deployment. The CONOPS may live inside a system security plan, a privacy plan, or a standalone document, but wherever it sits, it must evolve alongside the system it describes.

In practice, this means the CONOPS touches every phase of the system development life cycle. Design reviews should confirm that the operational concept still aligns with the system architecture and control implementations. When changes occur, those updates need to cascade into related documents, including procurement specifications, systems engineering artifacts, and security or privacy architecture documentation.

Why it matters

Organizations that skip a formal CONOPS often discover the gap during audits, when assessors ask how a system’s security posture was designed to function in production. Without a documented operational concept, your team can’t demonstrate that security and privacy were intentionally built into how the system runs, not just bolted on after the fact.

The consequences extend beyond audit findings. A missing or stale CONOPS creates operational risk by leaving security assumptions undocumented. When staff rotate or system ownership changes, institutional knowledge about how controls are supposed to function disappears with the people who held it. The result is configuration drift, inconsistent incident response, and controls that exist on paper but don’t match what’s actually deployed.

For organizations subject to federal oversight or operating under NIST SP 800-53, failing to maintain a CONOPS signals a broader weakness in security planning. Assessors treat it as evidence that the organization hasn’t thought through how security and privacy requirements translate into operational behavior, raising questions about the maturity of the entire Planning family. Even though PL-07 carries a low risk severity and isn’t included in any baseline, its absence raises questions about the maturity of your entire planning process.

Where this becomes especially visible is during continuous monitoring. Without a CONOPS that defines expected operational behavior, your team has no documented baseline against which to measure deviations. Security incidents take longer to detect because no one has written down what “normal” looks like for how controls are supposed to interact during routine operations.

What attackers exploit

The following gaps become exploitable when a CONOPS is absent or outdated:

• Undocumented security assumptions that lead to misconfigured controls, creating openings attackers can leverage
• Inconsistent operational procedures across teams, allowing security gaps to persist unnoticed
• Lack of clarity about how privacy protections are maintained during routine operations, increasing exposure of sensitive data
• Stale architecture references that don’t reflect current system boundaries, leaving new attack surfaces unmonitored

How to implement PL-07

Most organizations struggle with PL-07 not because the requirement is technically complex, but because a CONOPS sits in an awkward space between policy documents and technical architecture. The challenge is writing something specific enough to be operationally useful without duplicating what already exists in security plans and architecture documentation.

For your organization

1. Define scope and ownership

Assign a single owner, typically the system security officer or information system security manager, who is responsible for drafting and maintaining the CONOPS. Determine whether the CONOPS will be a standalone document or embedded within the system security plan or privacy plan. Either approach satisfies the requirement, but the choice should be deliberate and documented.

2. Draft the initial CONOPS

Build the document around these core elements:

• A description of how the system operates from the perspective of information security and privacy
• The security and privacy controls in place and how they function during normal operations
• Roles and responsibilities for maintaining the system’s security posture
• How the system interacts with other organizational systems and external boundaries
• Assumptions about the threat environment and how the system is designed to withstand it

3. Align with the system development life cycle

Integrate CONOPS reviews into existing life cycle milestones. During design reviews, verify that the CONOPS still reflects the planned control architecture. During testing phases, confirm that operational procedures match what the CONOPS describes. After deployment, compare actual operations against the documented concept and update accordingly.

4. Establish a review cadence

Define the frequency for periodic reviews. At minimum, trigger a review when significant system changes occur, including architecture modifications, control updates, or changes to the operational environment. Document each review, even when no changes are needed, to maintain an audit trail.

5. Cascade updates to related documents

When the CONOPS changes, update all downstream artifacts. Security plans, privacy plans, procurement specifications, and systems engineering documents should all reflect the current operational concept. This cross-document consistency is a common assessment finding when organizations update the CONOPS in isolation.

6. Validate through tabletop exercises

Specifically, test the CONOPS against realistic operational scenarios. Walk through how your team would respond to a system change, a new threat, or a control modification using only what the CONOPS documents. If participants need to rely on undocumented knowledge to answer questions, the CONOPS has gaps that need closing before the next review cycle.

Evidence of compliance

Cross-framework mapping

Related controls

• PL-02 — System Security and Privacy Plans: The CONOPS often lives within or directly feeds the system security plan and privacy plan. PL-02 establishes the broader planning documents that PL-07’s operational concept supports.
• SA-02 — Allocation of Resources: Developing and maintaining a CONOPS requires dedicated resources, and SA-02 ensures the organization budgets for security and privacy planning activities throughout the system life cycle.
• SI-12 — Information Management and Retention: The CONOPS defines how information is handled operationally, and SI-12 governs how that information is retained and disposed of in alignment with the documented operational concept.

Frequently asked questions

What is NIST SP 800-53 PL-07

PL-07 requires organizations to develop and maintain a concept of operations that describes how a system will be operated from the perspective of information security and privacy. The CONOPS captures the operational intent behind your security and privacy controls, bridging the gap between policy and day-to-day system behavior. It must be reviewed and updated at a defined frequency to ensure alignment with the current system architecture and control implementations.

What happens if PL-07 is not implemented

Without a CONOPS, your organization lacks a documented description of how security and privacy protections are intended to function in practice. Assessors evaluating your system security plan will find no operational narrative connecting implemented controls to their intended behavior. This gap typically results in audit findings related to planning maturity and can undermine confidence in the entire security program during authorization reviews.

How do you audit PL-07

Auditing PL-07 starts with verifying that a CONOPS exists for the system and that it addresses both information security and privacy operations. Assessors will examine the CONOPS for specificity, checking that it describes actual control implementations and operational procedures rather than restating policy language. They’ll also request dated review and update records to confirm the CONOPS is being maintained at the defined frequency, and they’ll compare it against the system security plan and privacy plan to verify cross-document consistency.

What is a CONOPS in cybersecurity

A CONOPS in cybersecurity is a document that describes how an organization intends to operate a system from the perspective of information security and privacy. Unlike a system security plan, which catalogs controls and their implementation status, the CONOPS focuses on operational intent, explaining how those controls work together during normal system operations. Organizations update it throughout the system development life cycle to keep it aligned with the current architecture and operational procedures.