PM-7, Enterprise Architecture, asks you to develop and maintain an enterprise architecture with consideration for information security, privacy and the resulting risk to operations, assets and individuals. Federal programs are bound by it, and contractors by agreement. Other companies can read it as: do your diagrams and standards show where security and privacy sit?
What it means in practice
The record says integrating security and privacy requirements into the enterprise architecture helps ensure they are addressed through the system development life cycle and tied to the mission and business processes. Security and privacy architectures are developed at a system of systems level, representing all organizational systems.
That is different from PL-8, where the architectures are developed for an individual system. The record says system level architectures must be consistent with the organizational ones. In a company, the organizational view might be a set of reference patterns: how identity works, where data is encrypted, how services talk to each other, which cloud accounts exist and why.
The record names the Risk Management Framework in SP 800-37 as the most effective way to integrate requirements and controls.
The record lists one enhancement, PM-7.1 Offloading. It covers moving certain functions or services to other systems or providers, for example handing a function to a specialized provider. The architecture should show these decisions and the risk they carry.
An architecture that lives in one engineer's head fails this control. The test is whether a new team can find the approved patterns and see where security and privacy requirements attach.
Evidence to collect
- Enterprise architecture documents or diagrams showing security and privacy components
- Reference architectures and standards for identity, data protection and networking
- Architecture review records for new systems
- Evidence that system level designs are checked against the organizational patterns
- For PM-7.1, a record of functions moved to other providers and the risk accepted
- Update history
Common gaps
- Diagrams show boxes and arrows but no trust boundaries or data flows
- Teams build systems that ignore the reference patterns
- Architecture reviews are optional
- Offloaded services appear nowhere in the architecture
- The documents are never updated
How to implement it
- Draw the organization level view: systems, trust boundaries, data stores and flows.
- Write short reference patterns for the repeat decisions.
- Require an architecture review for new systems and big changes, and keep the record.
- Tie reviews to the system inventory (PM-5) and to each system's architecture under PL-8.
- Document each offloaded function with its provider and risk.
Quick check
How does PM-7 differ from PL-8?
PM-7 covers organization level architectures across all systems. PL-8 covers the architecture for a single system, which must be consistent with the organizational one.
