PM-7 Enterprise architecture: requirements and evidence

PM-7 enterprise architecture: what the requirement asks for

The assessor or contract asks for PM-7, and the team already has architecture diagrams. The problem is that those diagrams were drawn to show application dependencies, capacity and cost, not security or privacy. PM-7 asks the organization to develop and maintain an enterprise architecture that takes information security, privacy and the resulting risk into account, and to do so at the organization level rather than system by system. The risk in view is wide: harm to organizational operations, assets, individuals, other organizations and the Nation that could follow from weaknesses in how systems, data flows and shared services fit together. Control PM-7 is therefore about whether security and privacy decisions are visible in the architecture that the enterprise uses to make investment and design choices.

The control is hard for a practical reason. Enterprise architecture documents are usually owned by enterprise IT, enterprise architecture or a platform group, while security and privacy teams own the control catalog, the risk register and the system security plans. Neither group holds the full picture, so the architecture is often silent on trust boundaries, data classification, privacy-relevant flows and shared security services. The first decision is who owns the enterprise architecture artifacts and who has authority to require security and privacy content in them. The second is whether the existing repository can hold that content without a parallel document that drifts out of date.

PM-7 also includes an enhancement on offloading functions to other systems. In practice, this asks the organization to show in its architecture where security or privacy functions, such as identity, logging, key management or consent handling, are moved to a shared or external system, and what risk that offload introduces. The related controls PL-8 (system-level architectures) and SA-8 (security and privacy engineering principles) should trace back to the enterprise view. Confirm with your assessor which artifacts they expect for PM-7 and how they want the offload enhancement evidenced, because the wording in the catalog and the assessment procedures in SP 800-53A set the test.

Which architectures and systems PM-7 puts in scope

PM-7 asks for one enterprise architecture that accounts for security, privacy and the risk it creates. The scoping questions below decide how wide that architecture reaches and how much evidence the organization must keep current, so settle them before drafting the architecture document.

The enterprise architecture itself

This is the organization-wide document set that describes how business units, shared platforms and data flows fit together and where security and privacy considerations sit. The scope decision is how many business units share one architecture. A single enterprise view across several units means one owner, one review cycle and one set of decisions to explain to an assessor. Confirm who approves the architecture and how often it is reviewed, since PM-7 expects it to be maintained, not just written once.

Business and mission processes

PM-7 requires the architecture to reflect the business and mission processes it supports, because security and privacy risk depends on what each process does with data and which outcomes it protects. Map the processes that handle regulated or sensitive information first, then trace them to the platforms they use. A process that depends on a single shared application should be documented once in the architecture and referenced by every system that relies on it. Confirm that process owners, not only IT staff, reviewed the mapping.

Shared services and common platforms

Identity providers, logging pipelines, backup services and container platforms are often shared across systems, so a weakness in one can affect many. The architecture should show each common platform, which systems depend on it and which security functions it provides to them. For self-hosted open-source platforms in the client's own infrastructure, record the hosting boundary, the administrators and the upgrade path. Ask whether each shared service has a documented owner and whether its failure is reflected in the risk discussion.

Third-party and cloud services

Where functions are offloaded to a provider, the architecture must show what the provider controls and what the organization still owns. The enhancement to PM-7 expects offloading of functions to other systems to be considered. Record each external service, the data it receives, its hosting location and the contractual or assessment evidence that covers it. A managed service that runs under a provider's responsibility model still needs its interfaces and residual risks documented on the organization's side.

System-level architectures under PL-8

PL-8 asks for system-level security and privacy architectures that align with the enterprise architecture. Each system's architecture should trace back to the enterprise view, so a reviewer can see which enterprise decisions a system inherits and which it changes. Check for mismatches, such as a system that uses a boundary control the enterprise document does not describe, or a system that stores data in a region the architecture does not list. Each alignment gap should become a tracked item rather than an unexplained difference.

Privacy-relevant data flows

The architecture must account for privacy risk, which means showing where personally identifiable information is collected, stored, shared and deleted across systems. Illustrative example: a customer record that moves from an intake application to an analytics service and then to a backup store creates three flows with different retention and access rules. Document each flow, its purpose and its endpoints, and confirm which flows cross organizational boundaries. Gaps here usually surface during privacy-focused assessment interviews.

Why PM-7 sits outside the baselines but inside the privacy baseline

PM-7 is not allocated to the low, moderate or high baselines, but it is included in the privacy baseline. The reason is how SP 800-53B classifies Program Management controls: they are deployed organization-wide to support the information security program, and they are independent of any system's impact level. So the security baselines do not select PM-7 for individual systems. The privacy baseline applies regardless of impact level, which is why PM-7 appears there. None of PM-7's enhancements is allocated to any baseline, so the one active enhancement carries no baseline obligation of its own.

For planning, treat PM-7 as one organization-level artifact rather than a per-system control set. The enterprise architecture is developed and maintained once at the organization level, and each system's architecture under PL-8 is then measured against it. Confirm with your assessor whether they expect the enterprise architecture to be scoped to the privacy baseline only, since the privacy baseline is the context in which PM-7 is selected. Also confirm who owns the artifact, how often it is reviewed, and how exceptions are recorded, because those decisions drive the evidence an assessor will request.

An assessor will read PM-7 alongside its related controls: PL-2 (system security and privacy plans), PL-8 (security and privacy architectures), PM-11 (mission and business process definition), RA-2 (security categorization), SA-3 (system development life cycle), SA-8 (security and privacy engineering principles), SA-17 (developer security and privacy architecture and design), and AU-6 (audit record review). Map each system's architecture documents back to the enterprise architecture so the chain of evidence is traceable. The NIST CPRT entry for PM-07 lists the official text and related controls for the current release.

How an assessor tests PM-7 enterprise architecture

This table groups the six SP 800-53A determination statements for PM-7 by examine, interview and test method, showing what the assessor asks for and where findings usually arise. Read each row as one line of evidence the organization should be ready to produce before the assessment starts.

Method and assessment object	Evidence requested	Common findings
Examine: enterprise architecture documentation	Current enterprise architecture documents that show security and privacy considerations, with version history and approval records	Architecture documents omit security or privacy views, or were last reviewed long before the assessment
Examine: enterprise architecture development procedures	Written procedures defining how the architecture is developed, reviewed and updated, including who signs off on changes	Procedures exist but do not mention security, privacy or resulting risk, or are not followed in practice
Interview: personnel responsible for developing the architecture	Named architects and their roles, plus their explanation of how security and privacy requirements reach architecture decisions	Staff cannot describe how risk to operations, individuals or assets feeds into design choices
Test: enterprise architecture development process	Records of a recent architecture review or change cycle showing security, privacy and risk inputs and decisions	The process is informal, with no repeatable steps or records of decisions made
Examine: linkage to system-level architectures	Evidence that system architectures under PL-8 align with the enterprise view, such as mapping documents or review minutes	System architectures are documented separately with no traceable link to the enterprise model
Test: maintenance and update cycle	Evidence the architecture is revised when systems, threats or privacy obligations change, such as dated revisions tied to triggering events	Architecture reflects an earlier state of the environment, and updates are not tied to a defined trigger or schedule

Building the enterprise architecture that PM-7 evidence depends on

This sequence turns PM-7 from a document that exists into an enterprise architecture with a named owner, a defined scope, documented security and privacy considerations, linked system architectures, recorded offloading decisions and a review cycle an assessor can test.

Name the accountable owner and set the architecture scope
Start by naming the individual accountable for the enterprise architecture and the group that develops it, usually the enterprise or security architecture function with input from privacy. Define which business units, mission and business processes, shared services and systems fall inside the scope, and state which parts of the organization are excluded and why. The output is an approved scope statement signed by the accountable official, stored with the program documentation. Confirm with your own governance team who holds approval authority, since the control leaves that choice to the organization.
Inventory the business processes and systems in scope
Build the inventory of the mission and business processes, information flows and systems the architecture must cover. Draw the inventory from your system inventory and business process records, so that the enterprise view and the PM-5 system inventory do not contradict each other. Record the owner, data types and external connections for each entry. The output is a current architecture repository where every in-scope process and system has an entry, and gaps are logged for follow-up rather than silently omitted.
Document security and privacy considerations and resulting risk
PM-7 requires the architecture to account for information security, privacy and the resulting risk to organizational operations, assets, individuals, other organizations and the Nation. For each element in the repository, document the security and privacy design decisions, such as trust boundaries, shared identity services and where personally identifiable information is processed. Record the risks these decisions create and link each one to an entry in the risk register, so that the architecture and risk management program refer to the same items. The output is a risk register extract with architecture references and a named risk owner for each entry.
Align system architectures with the enterprise view
Connect the enterprise architecture to the system-level architectures developed under PL-8, which PM-7 lists as a related control. For each system in the repository, confirm that its security architecture matches the enterprise patterns for identity, boundary protection, data handling and shared services, and record any deviation with a reason and an approver. Where a system departs from an enterprise pattern, the deviation should flow into the risk register. The output is a cross-reference table linking each system architecture to its enterprise element, with deviations documented and approved.
Document offloading decisions and responsible parties
The one active enhancement for PM-7 concerns offloading functions to other systems, so document each decision to move a security or privacy function to another system, service or provider. For each one, record the function moved, the receiving system or provider, the party responsible for operating it, the residual responsibilities that stay with the organization, and the evidence that will show the offloaded function works. Where the receiving party is an external provider, confirm the contract and supply chain terms with the procurement and risk teams. The output is an offloading register that the architecture repository references for every entry.
Set a review and update cadence
Define how often the enterprise architecture is reviewed and what triggers an earlier review, such as a significant change to a mission process, a new system category, a new offloading decision or a material change in privacy obligations. Assign the review to the accountable owner and record each review with its date, attendees, changes and approvals. Confirm the cadence with your governance team, because the control does not set a fixed interval in the supplied material. The output is a review record and a version-controlled repository history that an assessor can use to test that the architecture is maintained, not written once.

Evidence that satisfies PM-7 and how to keep it current

PM-7 is assessed by examining architecture documentation and procedures, interviewing the people who develop the architecture, and testing the development process. The cards below list the artifacts that let an assessor follow that chain, and the tooling that keeps them current.

Enterprise architecture document and approval

The architecture document is the primary examine object for PM-7. It should describe how security and privacy are considered in the enterprise design, not only the technology stack. Check that it carries a version, an owner and a record showing the accountable official approved it. An assessor will look for a clear link from the document to the procedure that produced it.

Enterprise architecture development procedure

The procedure defines how the architecture is developed and maintained, who takes part, what inputs are required and how security, privacy and resulting risk are weighed. It is the document an assessor compares against the process in practice. Confirm that it names triggers for updates, such as major system changes or new mission requirements, and that it is approved and reviewed on a schedule your organization sets.

Security and privacy considerations with linked risks

This register lists the security and privacy considerations the architecture addresses and ties each one to a risk entry in your risk management records. It shows PM-7 is not a narrative exercise. Check that each consideration has an owner, a current status and a reference to the risk it mitigates, and that privacy considerations reflect the PII your systems process.

Offloading decisions with responsible parties

PM-7 enhancement (1) asks organizations to consider offloading functions to other systems, services or providers. Record each offloading decision, the function moved, the receiving party and who remains accountable for the outcome. Confirm that decisions reference the contract, shared responsibility matrix or agreement that governs the arrangement.

Role descriptions for architecture owners

Interviews under the assessment procedure test whether the people named as responsible for enterprise architecture know their role. Keep role descriptions for architecture owners that state their authority, deliverables, reporting line and how they coordinate with security, privacy and risk leads. Confirm that the names in these descriptions match the assignments in your governance records.

Change history showing architecture reviews

A dated history of reviews and revisions shows the architecture is maintained rather than written once. Each entry should record what changed, who approved it and which security or privacy considerations were reassessed. Wiki-style tools such as XWiki keep version history of each page, recording what changed, when and by whom, with compare and rollback. BookStack assigns abilities through roles that can be set per shelf, book, chapter or page, so only approved editors can change the architecture. These tools hold the artifacts but do not make the architecture compliant on their own. Confirm the fit with your own environment and assessor expectations before relying on them.

What PM-7 enterprise architecture costs to meet

This table compares the cost components of meeting PM-7 by who is paid, whether the cost is one-time or recurring, what pushes it up and how to keep it down. NIST does not estimate compliance costs, so use the table to scope a quote, not to predict a total.

Cost component	One-time or recurring	What drives it up	How to keep it down
Architecture staff time to develop the document	One-time, then recurring upkeep	Number of business units, mission processes and systems in scope; age and fragmentation of existing diagrams	Reuse existing architecture artifacts; limit scope to mission-relevant processes
Tooling or licenses for the repository	Recurring	Commercial architecture suites with per-seat pricing; number of editors and reviewers	Self-hosted open-source wiki with version history, such as XWiki or BookStack; confirm licensing terms
Security and privacy review time	One-time, then recurring at each major change	Number of security and privacy concerns to reconcile; absence of a documented risk strategy to reference	Tie reviews to existing risk management and PM-9 outputs; agree a review checklist up front
External facilitation or review	Usually one-time, sometimes recurring	Number of external providers and integration points; lack of internal architecture ownership	Scope outside help to a defined deliverable; ask for written deliverables before work starts
Evidence upkeep between audits	Recurring	Frequency of architecture change; number of business units updating their own sections	Set a review cadence and assign owners; keep change history so reviewers can see what changed and when
Auditor sampling	Recurring at each assessment	Number of architecture versions and approval records the assessor samples; gaps in approval trails	Keep approved versions, dated reviews and interview-ready owners; ask the assessor for the sample scope in writing

Who builds, who prepares and who assesses PM-7

Your organization owns PM-7 in full. Enterprise architects set the architecture, security and privacy leads establish how security, privacy and resulting risk are considered within it, and an accountable owner approves the architecture and the decisions that come from it. No partner or assessor can take those decisions over, and an assessor will ask who made each one and when.

Enterprise architects: maintain the enterprise architecture documents, the reference models and the relationships between business functions, systems and shared services.
Security and privacy leads: define how security and privacy requirements enter architecture decisions, and record the resulting risk to operations, assets and individuals.
Accountable owner: formally approves the architecture and any offloading of functions to other systems, and sets the review cycle.
Operating staff: keep system-level architectures under PL-8 consistent with the enterprise view, and raise changes that the enterprise model does not yet reflect.
Decision records: keep dated approvals and rationale so that the architecture can be traced to named people.

Before engaging anyone, confirm that a named owner, a review cadence and a decision log already exist, because an outside party cannot supply those on your behalf.

Where PM-7 enterprise architecture efforts usually fall short

PM-7 asks for an enterprise architecture that accounts for security, privacy and the resulting risk, and most shortfalls come from treating the architecture as a network drawing rather than a governed working document. The cards below cover the gaps assessors most often find when they examine the documentation and interview the people who maintain it, with one practical fix for each.

Diagrams without security content

Many enterprise architecture files show network topology and application hosting but omit trust boundaries, security services, identity sources and data classifications. PM-7 requires the architecture to consider information security itself, so a diagram that cannot show where controls sit does not meet the intent. Add a layer that marks trust zones, authentication points, logging and key management services, and the classification of data crossing each boundary. Ask the architecture owner to walk an assessor through one business process end to end using only that document.

No named architecture owner

When the enterprise architecture belongs to no one, it is updated only when a project asks for a change, and assessors interviewing staff get different answers about who decides. PM-7 expects the organization to develop and maintain the architecture, so the interview evidence should point to a specific role. Record the accountable role, the people who contribute, and the review forum that approves changes. Confirm that the named person can explain security and privacy decisions in the architecture, not only the technology choices.

Offloaded functions left undocumented

The PM-7 enhancement addresses offloading functions to other systems, such as moving logging, identity or encryption to a shared platform or a provider. Teams often adopt these services without recording which security functions moved, who operates them and where responsibility now sits. Keep a register of each offloaded function with the receiving system, the owner, the data it touches and the agreement that governs it. Check that the register matches what the platform team actually runs.

System architectures not tied to the enterprise view

PL-8 system architectures are meant to align with the enterprise architecture, but project teams frequently document their own designs in isolation. Assessors look for traceability: a system design should name the enterprise services, standards and security patterns it relies on, and deviations should be recorded. Require each system security plan architecture section to reference the enterprise component it implements. Sample two systems and check that each reference resolves to a component the enterprise view actually describes.

No review after major change

An architecture that was accurate at approval can drift after a cloud migration, a new identity provider or an acquisition. PM-7 requires the architecture to be maintained, which means changes should trigger an update, not wait for an annual cycle. Define the events that force a review, such as new trust boundaries, retired services or changed hosting regions, and record each review with its date and approver. Use version history in your documentation tool so an assessor can see what changed and when.

Privacy data flows missing

Architecture documents often show where systems run but not how personally identifiable information moves between them, which leaves the privacy dimension of PM-7 unaddressed. Map the PII categories, the systems that collect, store, transmit and delete them, and any external recipients. Mark the flows that cross organizational or national boundaries. Confirm with the privacy office that the map matches the privacy impact assessments and the records of processing the organization maintains.

PM-7 enterprise architecture questions buyers ask

How much effort does PM-7 enterprise architecture take?

The effort depends on how many systems, business processes and external dependencies the enterprise architecture must cover, and on how much of that material already exists. PM-7 is a program-level control, so it is not allocated to the low, moderate or high baselines in SP 800-53B. It does appear in the privacy baseline, which applies regardless of impact level. Effort drivers include the number of business units, the maturity of existing architecture documents, how many systems already have current system-level architectures under PL-8, and how many people must be interviewed. NIST does not estimate implementation effort, so ask your assessor and your own architecture team to size the work against your environment before you agree on a plan.

How long does a first enterprise architecture version take?

No duration is supplied for this, so treat any timeline as something to agree in writing rather than assume. The main variables are whether an enterprise architecture already exists in some form, how many stakeholders must sign off on security and privacy considerations, and whether leadership has approved the architecture scope. A first version is usually easier to finish when it is limited to documented scope, with a defined review cycle, than when it attempts to model every system at once. Ask any implementation partner to show the milestones, the reviewers and the dependencies in a fixed-scope plan before work starts.

What does PM-7 require from the organization to succeed?

PM-7 needs a documented enterprise architecture that considers information security, privacy and the resulting risk to organizational operations and assets, individuals, other organizations and the Nation. The organization must own the work. In practice that means executive sponsorship, named owners for the architecture, input from security, privacy, risk and business leaders, and a recurring process to keep the architecture current as systems change. Without those elements, the artifact becomes a snapshot that an assessor will question. Confirm with your assessor which governance records they expect to see before you start.

Can our own team build PM-7 without outside help?

Often yes, if your architecture, security and privacy staff have the time and mandate to produce and maintain the material. Outside help is usually most useful for preparing templates, mapping existing systems to the architecture, documenting security and privacy considerations, and organizing evidence for an assessment. The organization still owns the controls and the decisions. An implementation partner prepares systems and evidence, and only an independent assessor or certification body issues assessment results. Make the split of responsibilities explicit in any written scope.

What will an assessor ask for when testing PM-7?

SP 800-53A Rev. 5 assesses PM-7 through six determination statements using examine, interview and test methods. An assessor will typically examine enterprise architecture documentation and the procedures that govern its development, interview the personnel responsible for developing it, and test the organizational process used to develop it. Expect to show current documents, version history, approval records, evidence that security and privacy considerations were reflected, and proof that the process runs in practice. Confirm the exact evidence expectations and sampling approach with your assessor before you collect material.

How does PM-7 relate to PL-8 security architecture?

PM-7 sits at the enterprise level, while PL-8 addresses the security and privacy architectures for individual systems. The two should align, so each system-level architecture reflects the enterprise architecture and its security and privacy considerations. NIST lists PL-8 among the related controls for PM-7, which is a useful signal for assessors looking for traceability. Practically, you should be able to trace a system's architecture back to enterprise principles, shared services and risk decisions. Confirm with your assessor how they expect that traceability to be demonstrated for your environment.

What does the offloading enhancement of PM-7 mean in practice?

The enhancement concerns offloading functions to other systems, meaning security or privacy functions that can be moved to a dedicated service rather than built into each system. In practice, the enterprise architecture should identify which functions are offloaded, to which systems or services, and how responsibility and assurance for those functions are maintained. Examples include centralized logging, identity services or shared key management, but any specific choice is illustrative and depends on your environment. Document the dependency, the owner of the receiving system and the evidence that the offloaded function operates as intended.

Who can issue the assessment result for PM-7?

Only an independent assessor, auditor or certification body issues an assessment result or report. The organization owns its controls and documents them, and an implementation partner can prepare the architecture, supporting records and evidence, but it does not assess or certify that work. Which assessor is appropriate depends on the framework and contract that requires SP 800-53, such as an agency, a FedRAMP process or a contractual obligation. Confirm with the requesting party which assessor types they accept before engaging anyone.

How DeployOpen supports PM-7 enterprise architecture work

DeployOpen helps organizations shape the enterprise architecture that PM-7 asks for, then builds the self-hosted open-source platforms that architecture describes inside the client's own infrastructure. Engagements are fixed-scope, and the organization owns the architecture, its risk decisions and its control evidence. DeployOpen prepares the systems and documentation for assessment, while independent assessors judge them.

How we scope

The written scope names the enterprise architecture documents, business units and systems that PM-7 work will cover.
We confirm which security and privacy considerations the architecture must address, and who in the organization approves them.
The scope lists the platforms, related system-level architectures under PL-8, and the offloaded functions to be documented.

How we build

We draft the enterprise architecture documentation with the organization, mapping security and privacy concerns to each architectural layer.
We configure self-hosted open-source platforms inside the client's cloud accounts, data centers or air-gapped networks to match the documented design.
We test the architecture decisions against the scoped design, recording gaps and the risk each gap creates for the organization.

How we hand over

Deliverables include the architecture documentation, version history, configuration records and a list of open risks, all owned by the client.
We walk the client's architects and security staff through the documents so they can answer assessor interview questions.
We organize evidence by the PM-7 determination statements so the organization or its assessor can review it directly.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
We can update the architecture when systems change, offloaded functions move, or new privacy or security requirements apply.
Confirm with DeployOpen during scoping which review cycle, change approvals and assessor access the retainer will include.