NIST SP 800-53 Rev 5 binds US federal systems, and reaches other organizations through contracts and flow down clauses. For everyone else it is a reference catalog: a detailed, public description of what a control can look like. PL-7, Concept of Operations, has two parts. Develop a CONOPS for the system describing how the organization intends to operate it from the perspective of information security and privacy. Review and update it on a defined schedule.
The guidance says the CONOPS can sit in the security or privacy plans or other life cycle documents, and that it is a living document. During design reviews it is checked for consistency with control design, architecture, and operating procedures.
What it means in practice
Think of it as the operating story. Who uses the system, what it does, how it is deployed and supported, what data flows through it, and what assumptions security depends on. Changes to it flow into the system plan, architecture, procurement specifications, and engineering documents.
Evidence to collect
- The CONOPS or the plan section that serves as one.
- Version history and review dates.
- Design review records showing it was checked.
Common gaps
- A CONOPS written at kickoff and never touched.
- No link to the system plan.
- Operating assumptions that engineers have never read.
How to implement it
Write two or three pages: users and roles, deployment, data flows, support model, assumptions. Review it at each major design change and annually, and record each review.
Quick check
Does it need to be a separate document?
No. The guidance lets it live inside the security or privacy plan, or other life cycle documents.
