Control statement
Develop and maintain an enterprise architecture with consideration for information security, privacy, and the resulting risk to organizational operations and assets, individuals, other organizations, and the Nation.
Discussion
The integration of security and privacy requirements and controls into the enterprise architecture helps to ensure that security and privacy considerations are addressed throughout the system development life cycle and are explicitly related to the organization’s mission and business processes. The process of security and privacy requirements integration also embeds into the enterprise architecture and the organization’s security and privacy architectures consistent with the organizational risk management strategy. For PM-7, security and privacy architectures are developed at a system-of-systems level, representing all organizational systems. For [PL-8](#pl-8) , the security and privacy architectures are developed at a level that represents an individual system. The system-level architectures are consistent with the security and privacy architectures defined for the organization. Security and privacy requirements and control integration are most effectively accomplished through the rigorous application of the Risk Management Framework [SP 800-37](#482e4c99-9dc4-41ad-bba8-0f3f0032c1f8) and supporting security standards and guidelines.
From control text to operational evidence
Use Enterprise Architecture as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to enterprise program governance, accountability, resources, metrics, and organization-wide risk decisions.
Implementation workflow
- Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
- Resolve each organization-defined parameter before declaring the control implemented.
- Document how the implementation satisfies every clause of the official control statement.
- Collect evidence as a normal byproduct of operation rather than only before an assessment.
- Review exceptions, changes, and monitoring results on a risk-based cadence.
Evidence examples
- program charters and policies
- governance meeting records
- risk and performance metrics
- resource and responsibility assignments
Common failure patterns
- program metrics count activity instead of outcomes
- system-level risks never reach enterprise governance
- responsibilities assigned without authority or resources
- privacy and security managed in separate silos
Questions practitioners should ask
- What risk decision is this control intended to support in this system?
- Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
- Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
- What event or threshold requires the implementation to be reviewed or changed?
Assessment objectives and methods
Show the assessment objective
- PM-07[01]an enterprise architecture is developed with consideration for information security;
- PM-07[02]an enterprise architecture is maintained with consideration for information security;
- PM-07[03]an enterprise architecture is developed with consideration for privacy;
- PM-07[04]an enterprise architecture is maintained with consideration for privacy;
- PM-07[05]an enterprise architecture is developed with consideration for the resulting risk to organizational operations and assets, individuals, other organizations, and the Nation;
- PM-07[06]an enterprise architecture is maintained with consideration for the resulting risk to organizational operations and assets, individuals, other organizations, and the Nation.
Examine
- Information security program plan
- privacy program plan
- enterprise architecture documentation
- procedures addressing enterprise architecture development
- results of risk assessments of enterprise architecture
- other relevant documents or records
Interview
- Organizational personnel with information security and privacy program planning and plan implementation responsibilities
- organizational personnel responsible for developing enterprise architecture
- organizational personnel responsible for risk assessments of enterprise architecture
- organizational personnel with information security and privacy responsibilities
Test
- Organizational processes for enterprise architecture development
- mechanisms supporting the enterprise architecture and its development
Related controls
These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.
Control enhancements
Enhancements add specificity, strength, or scope to the base control. Baseline badges show explicit selections in the official SP 800-53B OSCAL profiles.
PM-7(1) — Offloading
Offload [Organization-defined: non-essential functions or services] to other systems, system components, or an external provider.
Official discussion
Not every function or service that a system provides is essential to organizational mission or business functions. Printing or copying is an example of a non-essential but supporting service for an organization. Whenever feasible, such supportive but non-essential functions or services are not co-located with the functions or services that support essential mission or business functions. Maintaining such functions on the same system or system component increases the attack surface of the organization’s mission-essential functions or services. Moving supportive but non-essential functions to a non-critical system, system component, or external provider can also increase efficiency by putting those functions or services under the control of individuals or providers who are subject matter experts in the functions or services.
Organization-defined parameters (1)
Assessment objectives and methods
[Organization-defined: non-essential functions or services] are offloaded to other systems, system components, or an external provider.
Examine
- Information security program plan
- privacy program plan
- enterprise architecture documentation
- procedures addressing enterprise architecture development
- procedures for identifying and offloading functions or services
- results of risk assessments of enterprise architecture
- other relevant documents or records
Interview
- Organizational personnel with information security and privacy program planning and plan implementation responsibilities
- organizational personnel responsible for developing enterprise architecture
- organizational personnel responsible for risk assessments of enterprise architecture
- organizational personnel with information security and privacy responsibilities
Test
- Organizational processes for enterprise architecture development
- mechanisms supporting the enterprise architecture and its development
- mechanisms for offloading functions and services
Related controls
Authoritative sources
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. Official control requirements and interpretations remain with NIST and the responsible authorizing organization.