PM-7: Enterprise Architecture

Quick-reference card

What this control requires

PM-07 requires your organization to develop and maintain an enterprise architecture that integrates security and privacy requirements throughout every system’s life cycle. This control operates at the system-of-systems level, meaning it addresses how all organizational systems relate to each other and to the mission, not just individual system designs.

In practice, this means your enterprise architecture must account for how security and privacy controls map to business processes and organizational risk tolerance. PM-07 sits above system-level architecture work covered by PL-08, which handles individual system security and privacy architectures. The distinction matters because gaps at the enterprise level cascade into every system that inherits its assumptions.

The most effective way to meet PM-07 is through rigorous application of the risk management framework (RMF) defined in SP 800-37. Your enterprise architecture should document how security and privacy considerations align with the organizational risk management strategy and connect directly to mission and business objectives. Without that alignment, security requirements become disconnected checkboxes rather than meaningful risk-reduction decisions.

Specifically, the enterprise architecture must address the resulting risk to organizational operations, assets, individuals, other organizations, and the Nation. This scope is broader than what most organizations initially consider. It requires evaluating how architectural decisions in one system affect the security posture of interconnected systems and external stakeholders who depend on your organization’s services.

Why it matters

Most organizations treat enterprise architecture as an IT planning exercise and bolt security on afterward. That approach creates structural blind spots, because security and privacy requirements that aren’t woven into the architecture from the start tend to get lost between system boundaries, organizational handoffs, and procurement decisions.

When PM-07 isn’t implemented, audit findings accumulate around inconsistent security controls across systems that should share the same risk posture. Compliance teams struggle to demonstrate that the organization’s security program is coherent rather than a patchwork of system-level decisions made in isolation. For frameworks like NIST SP 800-53, auditors expect to see evidence that security and privacy requirements flow from the enterprise level down to individual systems.

The organizational risk compounds over time. Without an enterprise architecture that accounts for security, your organization can’t reliably perform security categorization across systems or ensure consistent baseline configurations. System owners make independent decisions about risk acceptance that may conflict with each other or with the organization’s stated tolerance.

Failure to maintain the architecture is just as consequential as failing to create one. Architectures that aren’t updated to reflect new systems, decommissioned assets, and evolving threats provide a false sense of coverage. Privacy requirements are especially vulnerable to this drift, because changes in data processing activities often don’t trigger the same architectural review that new system deployments do.

The security architect role becomes critical in this context. Without a designated liaison between IT architecture and the security program, architectural decisions happen without security input, and security teams inherit an environment they had no voice in shaping. That disconnect is where most PM-07 failures originate.

What attackers exploit

• Inconsistent security boundaries between systems, where enterprise-level architecture gaps leave unmonitored trust relationships that attackers traverse laterally
• Misaligned risk categorization, where systems handling sensitive data inherit a lower security baseline because the enterprise architecture didn’t flag the data flow
• Untracked dependencies between systems, where a compromise in one system propagates because the architecture didn’t map shared services, APIs, or credential stores
• Orphaned systems outside the architecture, where legacy or shadow IT assets aren’t covered by any security baseline and serve as initial access points
• Stale architecture documentation, where the documented architecture no longer reflects reality, giving security teams a false picture of system interconnections and data flows

How to implement

For your organization

The most common failure mode is treating enterprise architecture documentation as a one-time deliverable rather than a living artifact that changes with your environment. Organizations create an architecture diagram during a compliance push, then never update it when systems are added, decommissioned, or re-scoped.

Start by assigning ownership. A security architect or equivalent role should serve as the liaison between IT architecture teams and the security program. This role ensures that every architecture decision considers its security and privacy implications before implementation, not after.

Build your enterprise architecture documentation to include these components:

• A system inventory that maps every organizational system to its security categorization and applicable baselines
• Data flow diagrams showing how sensitive information moves between systems, including third-party integrations
• A mapping of security and privacy controls to business processes, demonstrating how controls support the organization’s mission
• Risk assessment results that evaluate the architecture itself, not just individual systems

Integrate this work into your system development life cycle (SDLC). Every new system proposal should be evaluated against the enterprise architecture before approval. Use your organization’s RMF implementation to ensure that system-level security plans (covered by PL-02) align with the enterprise-level architecture.

Conduct architecture reviews at least annually, or whenever significant changes occur. Significant changes include new system deployments, major infrastructure migrations, changes to organizational mission or business processes, and mergers or acquisitions that introduce new system boundaries. Document the review results and any decisions to accept, mitigate, or transfer architectural risks.

Privacy integration deserves specific attention. Your enterprise architecture should identify where personally identifiable information flows between systems and where privacy controls apply. Many organizations address privacy as a compliance function separate from the architecture, which creates gaps that auditors flag during Program Management control assessments.

Common mistakes to avoid:

• Documenting the architecture without performing a risk assessment of the architecture itself
• Failing to address privacy alongside security in the architecture
• Treating the enterprise architecture as separate from the risk management program rather than as a core input to it
• Not updating the architecture when systems are retired or replaced

Tooling categories that support PM-07 include enterprise architecture modeling platforms, configuration management databases, and attack surface management solutions that provide visibility into the actual state of your environment versus what the architecture documents describe.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently documented for PM-07.

Related controls

• AU-06 — Audit Record Review, Analysis, and Reporting: supports PM-07 by providing the audit data needed to verify that enterprise architecture security controls function as documented
• PL-02 — System Security and Privacy Plans: defines system-level security plans that must align with the enterprise architecture established by PM-07
• PL-08 — Security and Privacy Architectures: covers individual system architectures that must be consistent with the enterprise-level architecture PM-07 requires
• PM-11 — Mission and Business Process Definition: establishes the mission and business process context that PM-07’s enterprise architecture must reflect
• RA-02 — Security Categorization: provides the risk categorizations PM-07 uses to align security baselines across the enterprise architecture
• SA-03 — System Development Life Cycle: defines the SDLC processes where PM-07 requires security and privacy integration
• SA-08 — Security and Privacy Engineering Principles: supplies the engineering principles that inform enterprise architecture security decisions
• SA-17 — Developer Security and Privacy Architecture and Design: addresses developer-level architecture that must trace back to PM-07’s enterprise-level requirements

Frequently asked questions

What is NIST SP 800-53 PM-07

PM-07 requires organizations to develop and maintain an enterprise architecture that integrates information security and privacy requirements at the system-of-systems level. This control ensures that security considerations aren’t addressed in isolation for individual systems but are coordinated across the entire organizational environment. The enterprise architecture must account for the resulting risk to organizational operations, assets, individuals, other organizations, and the Nation. Your architecture documentation should demonstrate how security and privacy controls connect to business processes and align with the organizational risk management strategy.

What happens if PM-07 is not implemented

Without PM-07, your organization lacks a coherent enterprise-level view of how security and privacy controls relate to each other across systems. Audit findings typically surface as inconsistencies between system-level security plans and organizational risk tolerance, because individual system owners make security decisions without a shared architectural reference. The absence of enterprise architecture risk assessments means your organization can’t identify gaps in security coverage that exist between systems rather than within them. Compliance reviews for privacy program plans become significantly harder when there’s no documented architecture showing how privacy requirements flow across system boundaries.

How do you audit PM-07

Auditors verify PM-07 by examining enterprise architecture documentation for evidence that it was developed and maintained with consideration for both information security and privacy. They review architecture development procedures to confirm that security and privacy review gates exist in the process. Auditors also look for results of risk assessments conducted against the enterprise architecture itself, not just the individual systems within it. The key audit question is whether the architecture reflects the current state of the environment and whether changes to the architecture trigger corresponding updates to security and privacy controls.

How does enterprise architecture support the Risk Management Framework

Enterprise architecture serves as the structural foundation that the RMF operates within, connecting system-level security decisions to organizational mission and business processes. When the architecture accurately maps system interdependencies and data flows, the RMF steps of categorization, control selection, and authorization produce consistent results across the organization. Without that architectural context, risk management activities happen in silos, and organizations lose the ability to assess risk at the system-of-systems level that PM-07 requires. The architecture also enables organizations to identify which security controls satisfy requirements across multiple systems, reducing duplication while maintaining consistent vendor risk oversight and security posture.