PM-7: Enterprise Architecture

To meet the pm-7: enterprise architecture requirement, you must develop and maintain an enterprise architecture (EA) that explicitly incorporates security and privacy considerations and ties architectural decisions to risk impacts on operations, assets, individuals, other organizations, and the Nation ¹. Operationalize it by defining EA governance, producing current-state/target-state views, and retaining decision and risk evidence.

Key takeaways:

• Your EA must be a maintained decision system, not a one-time diagram pack, and it must address security and privacy risk impacts ¹.
• Examiners will ask how architecture decisions flow into system design, authorization, change management, and risk acceptance.
• Evidence matters: keep architecture artifacts plus the governance records that prove EA is used and updated.

PM-7 forces an uncomfortable truth into the open: your organization already has an “architecture,” even if it is undocumented, inconsistent, or driven by whoever ships fastest. The control requires you to develop and maintain an enterprise architecture with explicit consideration for information security, privacy, and resulting risks to operations and assets, individuals, other organizations, and the Nation ¹. For a Compliance Officer, CCO, or GRC lead, the practical goal is assessment-ready clarity: you need a defined EA scope, an owner and governance path, and a set of architecture views that connect business objectives to systems, data flows, and trust boundaries.

PM-7 usually fails in two ways. First, teams treat EA as “IT paperwork,” so it never connects to risk decisions. Second, teams produce diagrams but cannot show how those diagrams change when the environment changes (new cloud service, new third party, acquisition, new data type). This page gives you requirement-level implementation guidance: what to build, who must own it, what artifacts to keep, and how to survive an audit without scrambling for institutional memory.

Regulatory text

Requirement (PM-7): “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.” ¹

Operator interpretation: You must (1) produce an EA that reflects how the enterprise works (business, information/data, applications, technology), (2) embed security and privacy into those architectural views, and (3) keep the EA current and used in decision-making so risk impacts are understood and controlled ¹. “Maintain” is the operative word: auditors expect a repeatable update mechanism, not a static file share.

Plain-English interpretation (what PM-7 is asking for)

PM-7 asks you to run architecture like a governance function:

• Document how your organization is built and how information and services flow.
• Define target-state architecture principles (for example: identity-first access, encryption by default, data minimization).
• Require projects and platform teams to align to those principles or formally request an exception.
• Use the EA to identify and manage security/privacy risk introduced by architectural choices (multi-tenancy, data replication, third-party integrations, cross-border processing).

A practical test: if you had to explain your “approved way” to build and integrate systems to a new engineering leader, could you do it using controlled artifacts, and could you show where security and privacy requirements are baked into that way of working?

Who it applies to (entity and operational context)

PM-7 is commonly assessed in:

• Federal information systems and programs that use NIST SP 800-53 as their control baseline ².
• Contractor systems handling federal data, where NIST-aligned controls are imposed by contract, flow-down, or authorization requirements ².

Operationally, PM-7 applies wherever architecture decisions get made:

• Cloud landing zones, shared platform engineering, network segmentation, identity design.
• Data platforms, analytics environments, and AI/ML pipelines where privacy risk is driven by data movement and reuse.
• Third-party connectivity patterns (APIs, SSO federation, managed services) where architecture sets the boundaries of trust.

What you actually need to do (step-by-step)

1) Assign ownership and define EA scope

• Name an EA control owner (often Enterprise Architecture, CIO org, or CISO office) and document RACI across Security, Privacy, IT, Engineering, and Product.
• Define scope: enterprise-wide vs. business unit; include on-prem, cloud, SaaS, and key third-party integrations.

Deliverable: EA charter + RACI, approved by a governance body.

2) Establish EA governance that produces decisions

You need a mechanism that turns architecture into enforceable direction:

• Architecture review board (ARB) or design authority.
• Required triggers: new systems, major changes, new data types, new third-party connections, network boundary changes.
• Exception process: time-bounded waivers with documented compensating controls and explicit risk acceptance.

Deliverable: ARB/architecture review procedure, exception template, and risk acceptance workflow.

3) Build “current-state” architecture views that are audit-usable

Keep it simple and consistent. Most teams need these minimum views:

• System/application inventory with ownership and purpose.
• Data architecture view: key data domains, classification, major stores, and principal flows.
• Integration view: APIs, message buses, file transfers, identity federation, and third-party links.
• Network/trust boundary view: major zones/segments, ingress/egress points, administrative access paths.
• Security and privacy overlays: where encryption occurs, where authentication/authorization is enforced, where sensitive data is processed, and where privacy constraints apply.

Deliverable: a controlled repository (EA tool or well-managed documentation set) with versioning and change history.

4) Define target-state principles and standards that embed security and privacy

PM-7 is satisfied when architecture includes security/privacy “by design,” not appended controls. Examples of standards you can codify:

• Identity and access patterns (SSO, MFA, privileged access boundaries).
• Approved encryption approaches and key management boundaries.
• Logging/monitoring expectations and retention principles.
• Data minimization and purpose limitation rules for privacy-relevant datasets.
• Third-party connectivity standards (approved integration methods, segmentation, contract-required security patterns).

Deliverable: architecture principles/standards with approval and review cadence.

5) Connect EA to risk management and change execution

This is where audits are won:

• Require architecture reviews to produce a risk statement when deviations occur (what could go wrong, who is impacted, what mitigations exist).
• Tie architecture review outcomes to change management: no “go live” for high-impact changes without architectural sign-off or a documented exception.
• Map architecture artifacts to system authorization packages or security plans where applicable.

Deliverable: traceability matrix that shows how architecture decisions connect to security/privacy risk decisions ¹.

6) Maintain the EA (make it living)

“Maintain” needs an operating rhythm:

• Update triggers (new system, decommission, major vendor change, data flow change).
• Periodic reconciliation: compare inventories to cloud accounts, CMDB, identity provider, and network topology sources.
• Evidence that updates happen: tickets, pull requests, meeting minutes, and approved changes.

Deliverable: maintenance procedure + change log demonstrating ongoing upkeep ¹.

Required evidence and artifacts to retain

Keep artifacts that prove both existence and operation:

Governance

• EA charter and scope statement
• RACI and named control owner
• ARB/design review procedure
• Meeting agendas/minutes and decision logs
• Exception register with expiry dates and approvals
• Risk acceptance records linked to deviations

Architecture content

• Current-state diagrams (systems, data flows, trust boundaries)
• Target-state architecture principles and reference architectures
• Standards for identity, encryption, logging, segmentation, third-party connectivity
• Data classification and privacy annotation where relevant

Operational proof

• Change tickets referencing architecture review outcomes
• Architecture review checklists completed per project
• Version history and repository audit trail
• Crosswalk showing how EA considerations include security and privacy risk impacts ¹

Tip: auditors accept different tooling maturity levels, but they rarely accept missing traceability. A neat diagram without decision records often fails.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me your enterprise architecture and how it is kept current.” ¹
• “Where do security and privacy requirements appear in architecture artifacts, not only in policies?”
• “How do architecture decisions get enforced for new systems and material changes?”
• “How do you control and document exceptions? Who can accept the risk?”
• “How does your architecture account for third parties and interconnections?”
• “Prove the architecture influenced a real project decision in the last release cycle.”

Hangup pattern: teams can produce a Visio but cannot prove maintenance or governance. Solve that with decision logs and an exception register that is actively managed.

Frequent implementation mistakes and how to avoid them

1. EA exists as a slide deck, detached from engineering workflows.
   Fix: require architecture review gates in your SDLC/change process; store approvals with the work items.

2. Security and privacy are mentioned but not represented in views.
   Fix: add explicit overlays (trust boundaries, sensitive data processing nodes, third-party links) and require risk statements for deviations ¹.

3. No defined scope, so the EA is always “in progress.”
   Fix: define minimum viable scope (critical business services + supporting platforms + key data flows), then expand deliberately.

4. Exception handling is informal (“we’ll fix later”).
   Fix: formal waivers with expiry, compensating controls, and documented risk acceptance.

5. Architecture inventory doesn’t match reality.
   Fix: reconcile against authoritative sources (cloud accounts, IdP apps, network/security tools) and document the reconciliation process.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for PM-7, so you should treat PM-7 as an assessment and authorization readiness control rather than a standalone enforcement headline. The risk is still real: weak or stale architecture artifacts lead to missed trust boundaries, unmanaged third-party connections, and unclear ownership, which increases the chance of control gaps and unacceptable risk acceptance ¹.

Practical execution plan (30/60/90-day)

Use this as an execution sequence, not a time promise.

First 30 days (stabilize and define)

• Assign PM-7 control owner; publish EA scope and RACI.
• Stand up architecture governance: review triggers, decision log, exception workflow.
• Build an initial current-state inventory for in-scope systems and third-party connections.
• Define the minimum set of diagrams you will maintain and where they live (with versioning).

By 60 days (produce usable EA and connect to risk)

• Publish baseline architecture views: application, data flow, trust boundaries, integration map.
• Add security/privacy overlays and define required architecture review checklist items ¹.
• Implement exception register and risk acceptance path with clear approvers.
• Pilot architecture reviews on a small set of active initiatives; capture decisions and link them to tickets.

By 90 days (operate and prove maintenance)

• Expand coverage to remaining in-scope systems; reconcile inventories with operational sources.
• Publish target-state principles and reference patterns (identity, encryption, logging, third-party connectivity).
• Produce assessment-ready evidence: decision logs, exceptions with expiries, change records referencing architecture review.
• If you use Daydream for control operations, map PM-7 to a named owner, an implementation procedure, and recurring evidence artifacts so audits pull from a single source of truth ¹.

Frequently Asked Questions

What counts as “enterprise architecture” for PM-7 if we don’t have an EA team?

A documented set of architecture views plus a governance process that produces and records decisions is enough. PM-7 cares that you develop and maintain architecture with security and privacy risk considerations, not that you have a specific org structure ¹.

Do we need a formal EA tool to satisfy PM-7?

No. You need controlled artifacts, version history, and proof that architecture is updated and used in decisions. Many organizations meet PM-7 with well-governed repositories and consistent templates.

How do we show “consideration for privacy” in architecture artifacts?

Annotate where personal data is collected, processed, shared with third parties, or moved across boundaries, and tie those flows to approved patterns and exceptions. Keep records showing privacy review or sign-off for high-risk flows ¹.

What is the minimum evidence set an auditor will accept?

An EA charter/scope, current-state views, target-state principles, an operating governance process (minutes/decisions), and an exception register with risk acceptance records. Without operational proof of maintenance, most programs struggle to demonstrate PM-7 ¹.

How do we handle third-party SaaS and managed services in the EA?

Treat key SaaS and managed services as architectural components with documented data flows, identity integration, and trust boundaries. Record architectural standards for third-party connectivity and capture exceptions when a service cannot meet them.

How often must we update the enterprise architecture?

PM-7 does not specify a fixed cadence in the provided text. Define update triggers tied to material changes and run periodic reconciliation so you can prove the EA stays accurate over time ¹.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5