PL-7 Concept of operations: requirements and evidence

What PL-7 concept of operations asks for and why no baseline includes it

PL-7 requires a concept of operations (CONOPS) for the system that describes how the organization intends to operate it from an information security and privacy perspective, and that CONOPS must be reviewed and updated at a defined frequency. It is a short, practical document about how the system is run day to day, not a design specification. You will usually meet this control when an assessor asks for it during a control review, or when a contract or agency requires it and the team either has nothing on file or has a document that no longer matches how the system operates. Before you start writing, confirm which frequency your authorizing body or contract expects, because the control leaves that value to the organization to define.

The reason no SP 800-53B baseline includes PL-7 is that NIST leaves it out of the low, moderate, high and privacy baselines. It appears in a system's control set only when tailoring adds it, because risk or an applicable requirement calls for it. That makes the first decision a documented one: record whether PL-7 is in scope for your system and why. If it is out of scope, the tailoring record should say so. If it is in scope, an assessor will expect the CONOPS to explain the operating model that the other controls depend on, since operators and assessors cannot judge whether controls fit real operations without a description of those operations. Confirm this decision with your assessor early, because a missing CONOPS is easy to overlook until review.

PL-7 is hard to keep accurate because it describes practice, and practice changes. Staffing shifts, new administrative paths, outsourced monitoring and cloud changes can each make the CONOPS wrong without anyone editing it. Treat it as a living document with a named owner, a review trigger tied to significant changes, and a check against the system security and privacy plan under PL-2, which it should agree with. SA-2 on resource allocation and SI-12 on information management and retention are related controls that touch the same operating decisions, so reviewing them together avoids contradictions. Their connections are real, but each has its own requirements, so do not assume that meeting one satisfies another.

Which systems and decisions put PL-7 in scope

PL-7 is not in any SP 800-53B baseline, so the question is rarely whether it applies by default. It usually arrives through a decision: a tailoring choice, an authorizing official's request, or a contract clause. The cards below cover the triggers that bring it in, the teams that feed it, and how shared environments split the writing.

Tailoring decisions under SP 800-53B

PL-7 sits outside the low, moderate and high baselines and the privacy baseline, so it enters only when the team supplements a baseline during tailoring. Record the reason in the tailoring worksheet, whether it is a risk finding, a contract term or a known gap in operational intent. Without a recorded reason, assessors will ask why a planning artifact exists for one system and not another. Confirm the decision with the authorizing official before the plan is drafted.

Impact level and contract requirements

A high-impact system, or a system whose customer contract names SP 800-53 as a requirement, is the most common reason a CONOPS is requested. Read the contract's control list and the system's categorization together, because a clause can add PL-7 even when the impact level does not. Ask the buyer whether they expect a standalone document or content inside the system security plan, since that changes where the CONOPS lives and who signs it.

Authorizing official and assessor requests

An authorizing official may ask for a CONOPS during authorization review when the system's operating model is hard to follow from the plan alone, such as a system with remote administration, rotating operators or overnight monitoring. Assessors test PL-7 through examine, interview and test methods, so the first question is usually whether the organization has procedures for developing and updating the CONOPS. Ask the assessor early which of these they will sample.

Operations, security and privacy owners

The CONOPS describes how the system runs day to day, so operations staff who schedule patching, backups and monitoring must supply the operating model. Security and privacy staff define the protections and the handling of personal information that the document must state. System owners approve the content and decide when it changes. Name each owner in the document and in the review procedure so that updates after a change have a clear route to sign-off.

Development teams and release changes

Developers feed the CONOPS with release cadence, deployment pipelines, emergency change paths and where code runs, all of which affect how the system is operated. Each significant change to pipelines or hosting can make a section stale. Agree with the development lead which changes trigger a CONOPS review, so that the update is part of the change record rather than a separate task found during assessment.

Third parties and inherited environments

When a cloud provider, managed service or outsourced operations team runs part of the system, the CONOPS must say which operator performs which action and how the organization oversees it. In a shared or inherited environment, the provider may own some operating procedures while the organization owns others. Map each operating activity to an owner, and confirm with the provider which parts of its operating model the organization can describe and which it can only reference.

How an assessor tests PL-7 under SP 800-53A

This table maps the two SP 800-53A determination statements for PL-7 to the examine, interview and test methods an assessor uses, the objects each method touches, the evidence to prepare and the findings that commonly appear. Read each row as one assessment thread, and treat the evidence column as the minimum set to have ready before fieldwork begins.

Method and assessment object	Evidence requested	Common findings
Examine: procedures for CONOPS development and for reviews and updates	Written procedure stating who drafts the security and privacy CONOPS, what it must cover, the review trigger and the review frequency the organization defined	Procedure exists but names no owner, or the review frequency is defined in the policy and never referenced in the procedure
Examine: the security and privacy CONOPS for the system	Current CONOPS with a version history, approval record and a statement of how the system is operated from security and privacy perspectives	CONOPS describes an earlier system state, omits privacy operations, or lacks an approval date
Interview: personnel with planning and plan implementation responsibilities	Named role holders, their responsibilities for the CONOPS, and examples of how they used it in operations or change decisions	Staff cannot describe the CONOPS or say it has never been used to guide an operational decision
Test: organizational process for developing, reviewing and updating the security CONOPS	Records of at least one completed review cycle, change requests that triggered an update, and sign-off showing the process was followed	No review record exists for the stated period, or updates are made informally without a documented trigger
Determination link: how the two statements connect	Traceability from the procedure to the CONOPS and from the CONOPS to the review records, so each statement can be tied to artifacts	Assessor cannot trace the CONOPS to a procedure, so the organization is asked to produce additional records during the assessment

How to write and maintain a PL-7 CONOPS for the system

This sequence takes an organization from confirming that PL-7 applies to a system through to a reviewed, approved and version-controlled concept of operations that stays aligned with the security and privacy plans that implement it.

Confirm PL-7 applies and record why
Start by checking whether PL-7 is in the system's selected control set. SP 800-53B does not allocate PL-7 to the low, moderate, high or privacy baselines, so it is usually added during tailoring when risk or an applicable requirement calls for it. Record the reason in the tailoring decision, along with the requirement or risk that justifies it. Done when the system's control selection shows PL-7 with a stated rationale that an assessor can trace.
Name the system owner and contributors
Assign one accountable owner for the CONOPS, normally the person responsible for operating the system. List the contributors who will supply input: operations, security, privacy, development and any service providers that run part of the system. Confirm that the owner has authority to approve statements about how the system is run. Done when the owner and contributors are named in the document header with their responsibilities written down.
Describe the operating model and personnel roles
Write how the system is run from day to day: who operates it, who administers access, who responds to alerts, and who makes changes. Name roles rather than individuals so the text survives staff turnover. Include which parts are run in-house and which are delegated to external parties. Done when every operational function has a named role and an accountable owner that a reviewer can check against the organization chart.
Map data flows at an operator's level
Describe the main data flows in terms operators already use: where data enters, where it is stored, how it moves between components, and where it leaves the system. Include the privacy-relevant points, such as where personal information is collected or shared. Keep the level of detail high enough to explain operations but not so detailed that it duplicates the architecture document. Done when an operator can read the flows and recognize the system they work on.
Link each statement to its controls and plans
For each operational statement, point to the control or plan that implements it, such as the system security and privacy plan, the incident response plan, the configuration baseline or the monitoring strategy. A statement with no link is a candidate for removal or for a new control. Keep the links to document identifiers and section names. Done when a reviewer can start from any statement in the CONOPS and find the implementing document without asking the author.
Set the review frequency and update triggers
The organization defines the review frequency for the CONOPS. NIST does not set it, so record the interval chosen and the reason for it in the policy or procedure that governs the document. Add event-driven triggers as well, such as significant changes to the system, changes in the operating model, new external dependencies, or incidents that expose a gap in the described operations. Confirm the triggers with the system owner. Done when the review cycle and triggers are written in the document and reflected in the governing procedure.
Obtain review and approval
Route the draft to the contributors for technical accuracy and to the security and privacy leads for consistency with the system security and privacy plan. Resolve conflicts between the CONOPS and the plan before approval, because an assessor will test them against each other. Record the approver and the approval date. Done when the approved version is filed and every statement has been checked by at least one person who operates the system.
Assign a change log and version history
Keep the CONOPS under version control so every change records what changed, when and by whom. Store the document in a system that allows comparison between versions and rollback to earlier versions, such as a wiki with page history or a documentation platform with role-based permissions. Restrict edit rights to the owner and approved contributors. Done when the change log shows each approved version and the trigger that prompted it, ready for an assessor to examine.

Which evidence passes a PL-7 assessment

An assessor testing PL-7 looks for a CONOPS that exists, was approved, is reviewed on the defined schedule, and is actually used by the people who plan and run the system. The cards below cover the artifacts that show each of those points and how to keep them current between assessments.

Approved system CONOPS with version and date

The core artifact is the CONOPS itself, describing how the organization intends to operate the system from an information security and privacy perspective. Assessors check that it names the system, carries a version and date, shows who approved it, and covers the security and privacy operating picture rather than only system features. Confirm that the approved version is the one the team actually works from, not a draft kept beside it.

CONOPS development and review procedure

Assessors examine the procedures that govern how the CONOPS is developed, reviewed and updated. These should name the owner, the contributors, the review trigger and the approval step. Without a written procedure, an assessor has no basis for judging whether the CONOPS reflects a repeatable process or a one-time document. Check that the procedure matches what the team does in practice.

Review and update record

This record shows that the defined review frequency and event-driven triggers were followed, such as major architecture changes, new mission functions or changes in threat conditions. Each entry should state the date, the reviewer, what was checked and what changed or was confirmed unchanged. Gaps between scheduled reviews are the most common finding, so the record should show every cycle, including those with no edits.

Change history of the document

A change history records each edit to the CONOPS, including what changed, when and by whom. It lets an assessor trace how the operating picture evolved over the system life cycle and confirm that changes were reviewed rather than made quietly. Confirm that the history is kept by the document system itself and that it cannot be edited after the fact, since a history that anyone can rewrite carries little weight.

Sign-offs showing personnel use the CONOPS

The control expects the CONOPS to inform planning and operation, so assessors interview personnel with planning and plan implementation responsibilities. Review sign-offs, acknowledgments or meeting records from those people show that the CONOPS is known and used. Ask whether the staff who run the system can name where the current CONOPS lives and what it says about their responsibilities.

Traceable link between the CONOPS and the SSP

The CONOPS should align with the system security and privacy plan (PL-2) and the related controls that the catalog lists for PL-7, including SA-2 and SI-12. An assessor will check that operating decisions in the CONOPS match the controls, responsibilities and boundaries in the SSP. A cross-reference table or traceability matrix, kept current with both documents, makes that check quick and exposes contradictions early.

Keeping evidence current between audits

Between assessments, schedule reviews on the defined frequency, record every change with a reason, and retain prior versions so the history stays complete. Self-hosted wikis with version history can hold the CONOPS and its record. XWiki keeps every change under version control and lets users compare and roll back versions, while BookStack assigns abilities by role and allows overrides per role at the shelf, book, chapter or page level. Confirm each platform's current feature set and license terms directly with the vendor before relying on them.

What a PL-7 CONOPS costs in staff time and upkeep

The table lists each cost component of a PL-7 concept of operations, who carries it, whether it is one-time or recurring, and what pushes it up or down. Use it to shape a written scope before asking partners or auditors for a quote, since NIST does not estimate compliance costs and no figures for this control are supplied here.

Cost component	Who carries it	One-time or recurring	Drivers and how to keep it down
Drafting the CONOPS	System owner with security and privacy staff	One-time, then recurring with each revision	Drivers: number of operating modes and teams. Keep it down by reusing existing operating procedures and writing to the system boundary only.
Operations and engineering input	Operations, platform and engineering leads	One-time for the first draft, recurring at each review	Drivers: number of shared environments and external service providers. Keep it down by collecting input once through a standing template.
Security and privacy staff review	Information security and privacy office	Recurring at the defined review frequency	Drivers: privacy processing scope and how many parties must agree. Keep it down by agreeing review criteria in advance.
Approval time	Accountable official or designated approver	Recurring at each approval cycle	Drivers: number of approval layers. Keep it down by naming one approver and a written escalation path.
Change-driven updates	System owner and change board	Recurring, tied to change events	Drivers: change rate, major architecture changes and incidents. Keep it down by linking CONOPS updates to existing change tickets.
Tooling and hosting	Platform or IT team	Recurring if self-hosted; license spend removed for open-source wikis	A self-hosted wiki such as XWiki or BookStack can remove license spend, but hosting, backup, patching and administration still need staff time. Confirm the hosting and support model with the platform team.
Assessor time to examine and interview	Independent assessor, paid by the organization	Recurring at each assessment cycle	Drivers: number of interviews and document sets requested. Keep it down by keeping version history and the review record in one place.
External help for drafting or review	Implementation partner or consultant, by written scope	One-time for drafting, optional recurring for review	Drivers: internal skills gaps and scope of the system. Ask for a written scope, deliverables and a fixed quote before work starts.

What to outsource for PL-7 and where the auditor draws the line

Your organization owns the concept of operations. The CONOPS describes how you intend to operate the system from an information security and privacy perspective, so the operating decisions in it must come from people accountable for the system. Those decisions include how the system is used, who operates it, which functions are in or out of scope, how it changes over its life cycle and what risks leadership accepts. Approval is also yours. An assessor will look for evidence that the authorizing or accountable official reviewed and approved the document, and no partner can supply that approval.

Operating decisions: Define the mission purpose, user populations, operating model and the boundaries of what the system does and does not do.
Security and privacy intent: Decide how the system is expected to protect information and privacy, and which trade-offs leadership has accepted.
Approval and sign-off: Record who reviews the CONOPS, who approves it and when, and keep that record with the document.
Review triggers: Set the review frequency and the events that force an update, such as a significant architecture change or a new data type.
Staff ownership: Name the people responsible for keeping the CONOPS current and for answering assessor interviews.

Before engaging any partner, confirm internally who holds these decisions, because the rest of the work depends on them.

Where PL-7 usually fails and how to close each gap

A PL-7 concept of operations usually fails on paper before it fails in an assessment. The gaps below share a root cause: the document is treated as a one-time narrative rather than a living statement of how the system is run. Each card names the gap and the action that closes it, so the owner can check the CONOPS against what the assessor will examine.

Describes the design, not the operation

A CONOPS that restates the architecture diagram and intended functions describes the system as designed. PL-7 asks how the organization intends to operate the system, so the document must cover who runs it, how changes reach production, how alerts are handled and how access is granted day to day. Close the gap by walking one real operating cycle, such as a routine patch or a new user request, and writing down each step and role as it actually happens.

No review frequency or triggers

Many CONOPS documents carry a date from the original authorization and nothing else. The control expects the document to be reviewed and updated at a defined frequency, so the organization must set that frequency in its own procedures and record it. Add event-based triggers as well, such as a new hosting region, a change in the authorization boundary, a major release or a significant incident. Confirm the frequency against the PL-1 policy, since assessors check that the two agree.

No named owner or approval record

A CONOPS with no accountable owner has no one to answer an assessor's interview questions about it. Name the role that owns the document, the role that approves it and the authorizing official or designee who accepts it for the system. Keep a signed approval or workflow record with each version. Interviews under the SP 800-53A procedure cover planning and plan implementation personnel, so the people named in the document should be able to explain it.

Conflicts with the SSP or rules of behavior

The CONOPS, the system security and privacy plan (PL-2) and the rules of behavior (PL-4) describe overlapping facts, such as who may administer the system and which tools staff may use. When they disagree, assessors treat the disagreement as a finding in its own right. Before each review, compare named roles, access paths, remote support methods and data handling statements across the three documents, and correct every mismatch in the same change set.

No change history to show updates

An updated CONOPS with no record of what changed, when and by whom cannot show that the review cycle ran. Store every version in a system that keeps history, so that a reviewer can compare any two versions and see the reason for each edit. Wiki platforms such as XWiki record version history of this kind, and BookStack can restrict who may edit or approve pages. Confirm the retention period for old versions with the organization's records policy before you rely on them as evidence.

Written for inherited environments without scope

A CONOPS written once for a platform that runs on a cloud provider or a shared service often leaves out which operating activities belong to the inheriting system and which belong to the provider. Assessors then cannot tell what the organization must evidence itself. For each operating activity, state whether it is inherited, shared or owned locally, and reference the provider's responsibility documentation or the common control definition that supports the claim. Illustrative example: a provider runs physical hosting, while the organization still runs account reviews and log monitoring.

Questions buyers ask about PL-7 implementation

Is PL-7 required in every SP 800-53 baseline?

No. SP 800-53B does not allocate PL-7 to the low, moderate or high security control baselines, or to the privacy control baseline. Organizations add it during tailoring when their risk assessment or an applicable requirement calls for a CONOPS. A contract, agency or authorizing official may require it, so check the written requirements for your system before you decide it is out of scope. Document the decision either way, since the tailoring rationale is what an assessor will read.

How long does it take to write a CONOPS for a system?

The duration depends on how complex the system is and how quickly operators can give you time. No fixed duration is supplied for this control, so do not accept a timeline that is not tied to a written scope. Ask any partner for a scope that lists the systems covered, the operating modes to describe, the number of interviews, the review cycle and the approval steps. The scope is the input that makes a schedule defensible, and it should be agreed in writing before work starts.

What does the organization need to provide for a CONOPS?

The organization needs three things: named owners, operations input and approval time. The owner is the person accountable for the CONOPS and its review cycle. Operations staff, administrators and security personnel supply the description of how the system is run day to day, including monitoring, change handling and incident coordination. Leadership or the designated approver must sign off the final document. Missing any of these usually causes the schedule to slip, so confirm availability before the work begins.

Can our own team write the CONOPS in-house?

Yes. The control asks for a document that describes how the organization intends to operate the system from an information security and privacy perspective, and it must be reviewed and updated at a defined frequency. Your team can write it using the organization's own procedure and templates, provided the people who run the system contribute the operational detail. An outside review of the draft is an option if you want a second reader before an assessor sees it, but that review does not replace the organization's approval.

What drives the cost of a CONOPS up?

Cost follows the amount of work and the number of people whose time it takes. The main drivers are the number of systems and interfaces covered, how many operating modes and external dependencies must be described, how much of the operational detail is undocumented, how many reviewers and approvers are involved, and how often the CONOPS must be updated. Writing from scratch costs more than updating an existing document. Ask any quote to itemize these drivers, state who performs each task, and identify which parts are one-time and which recur at each review.

Can a partner sign the CONOPS or issue an assessment report?

No. The organization owns its controls and approves its CONOPS, so the approval comes from its own designated authority. An implementation partner can prepare the document, the supporting systems and the evidence an assessor will examine. Conclusions about whether the control is met come from an independent assessor or the organization's authorizing process, not from the partner who helped prepare the material. Make sure the written scope states this division of roles.

What evidence shows the CONOPS is kept current?

Assessors look for the CONOPS for the system, the procedures for developing, reviewing and updating it, and evidence that reviews happened at the defined frequency. Version history matters here. Self-hosted wiki platforms such as XWiki keep every change under version control, recording what changed, when and by whom, and let users compare versions and roll back. Keep a dated approval record alongside the document so the reviewer can see who signed each version.

How DeployOpen prepares PL-7 evidence for your system

DeployOpen works on PL-7 as part of the system's planning documentation, not as a standalone paper exercise. We help the organization write a concept of operations that matches how the self-hosted platform is actually run, then set up the review cycle and records that keep it current. The organization owns the CONOPS and its content; DeployOpen prepares the systems and evidence around it.

How we scope

Agree in writing which systems, environments and operating teams the PL-7 CONOPS will cover.
Confirm with the organization which baseline or tailoring decision brings PL-7 into scope, since SP 800-53B does not assign it to a baseline.
Set the review and update frequency the organization will commit to, recorded in the fixed-scope agreement before work starts.

How we build

Draft the CONOPS narrative covering how the self-hosted platform is operated from an information security and privacy perspective.
Align the CONOPS with the related PL-2 system security plan, PL-8 architecture and PL-1 policy so the documents do not contradict each other.
Test that the described operating processes match configured tooling, access paths and monitoring in the client's own environment.

How we hand over

Deliver the approved CONOPS document, its revision history and the review schedule in formats the organization controls.
Provide a short evidence map showing which records an assessor would examine and interview owners for under the PL-7 procedure.
Walk the organization's planning and operations staff through the document and the steps for keeping it up to date.

How we support

Update the CONOPS when the system, operating model or authorization boundary changes, under a documented change process.
Available as a retainer for periodic reviews, evidence refreshes and support during an assessment or authorization cycle.
Final approval of the CONOPS and any assessment conclusions rest with the organization and its independent assessor, not DeployOpen.