PL-2(2): Functional Architecture

PL-2(2) requires you to document and maintain a functional architecture for the system covered by your System Security Plan (SSP), and to keep it aligned to how the system actually works. Operationalize it by producing an architecture view that clearly shows major system functions, components, data flows, and trust boundaries, then tying that view to security controls and change management. ¹

Key takeaways:

• Build a functional architecture that shows what the system does, how it’s composed, and where data moves, not a vague “network diagram.”
• Tie the architecture to control implementation and update it through the same change process as production changes.
• Keep assessor-ready evidence: diagrams, narrative, mapping to boundaries/interfaces, and a change log. ²

The pl-2(2): functional architecture requirement is a planning control enhancement in the NIST SP 800-53 Rev. 5 PL family. In practice, assessors use it as a fast proxy for “do you understand your system well enough to secure it,” because architecture clarity drives scoping, boundary definition, control inheritance, and risk decisions. ²

Most teams fail PL-2(2) in a predictable way: they have diagrams, but they are stale, overly technical in the wrong places, or disconnected from the SSP and the way controls are implemented. A functional architecture is not your full engineering blueprint. It is the minimal set of architecture views and narrative that makes system function, component responsibilities, interfaces, and trust boundaries unambiguous to a reviewer. ¹

This page is written for a Compliance Officer, CCO, or GRC lead who needs to implement PL-2(2) quickly and defensibly. It tells you who owns what, what artifacts to produce, how to keep them current through change management, and what exam questions to expect.

Regulatory text

Requirement: “NIST SP 800-53 control PL-2.2.” ¹

What an operator must do: Treat PL-2(2) as an SSP architecture requirement. You must produce a functional architecture description for the in-scope system and maintain it as the system changes. The output should let a security reviewer understand:

• What the system’s major functions are (business and security-relevant functions)
• What components perform those functions (services, platforms, external dependencies)
• How data flows between components and across boundaries
• Where trust boundaries exist and what interfaces cross them
  Then, use that architecture to support security planning and control implementation in the SSP. ²

Plain-English interpretation (what PL-2(2) is really asking)

A functional architecture answers: “What does this system do, what is it made of, and how does information move through it?” If you cannot explain that cleanly, you cannot credibly claim your controls are correctly scoped or operating.

This is different from:

• A purely physical/network diagram (useful, but often misses SaaS dependencies, identity plane, and control points)
• A product whiteboard (often missing boundaries, interfaces, and data classification)
• A CMDB export (inventory is not architecture)

Your target is a set of architecture views that connect system purpose to concrete components, interfaces, and trust boundaries in a way a third party assessor can validate.

Who it applies to (entity and operational context)

PL-2(2) applies wherever you use NIST SP 800-53 Rev. 5 as the control baseline, including:

• Federal information systems operating under NIST control baselines ²
• Contractor systems handling federal data where NIST SP 800-53 is contractually required or flowed down ²

Operationally, it applies to the defined system boundary in your SSP. If your environment is hybrid (on-prem + cloud + SaaS), the functional architecture must include those external services that perform system functions or store/process/transmit system data, even if some controls are inherited.

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

1) Assign ownership and scope

• Control owner: Usually the System Owner or ISSO, with an Architecture/Engineering lead as the primary author.
• Scope anchor: Your SSP system boundary and authorization boundary.
• Working rule: If it processes, stores, transmits, or governs access to in-scope data, it belongs in the functional architecture.

Deliverable: A one-page “PL-2(2) implementation statement” in your SSP that names the canonical architecture artifacts and where they live. ²

2) Build the functional architecture views (minimum set)

Create (or standardize) a small set of views that you can keep current:

A. Functional decomposition

• List major functions (for example: identity and access, ingestion, processing, storage, analytics, audit logging, admin, customer access).
• Map each function to the component(s) that implement it.

B. Component diagram (logical)

• Show major services, databases, message buses, identity provider, key management, logging pipeline, and admin tooling.
• Clearly mark managed services and third party/SaaS dependencies.

C. Data flow diagram

• Show key flows for sensitive data types and operational logs.
• Mark ingress/egress points (APIs, file transfer, user access, admin access).

D. Trust boundaries and interfaces

• Explicitly label boundaries (for example: public internet, internal VPC/VNet segments, admin network, third party boundary).
• Identify interfaces crossing boundaries and their authentication/authorization model at a high level.

Practical standard: Keep the diagrams readable in black-and-white and printable. If a diagram needs a live tool to interpret, assessors will treat it as fragile evidence.

3) Tie architecture to security control implementation

PL-2(2) becomes real when the architecture informs your SSP control narratives:

• Boundary and inheritance: Use the trust boundary view to justify which controls are inherited from cloud providers or shared services.
• Access paths: Use the data flow + trust boundaries to validate AC, IA, and SC control statements (where auth happens, where encryption terminates, where sessions are managed).
• Logging and monitoring: Use component/data-flow views to show where audit records originate and where they are centralized.

Artifact: A simple mapping table: architecture element → SSP section/control topics it supports (for example: “Identity Provider” → access control and identification/authentication narratives). ²

4) Put the architecture under change control

Most PL-2(2) findings are “document exists but is outdated.” Fix that with process:

• Define “architecture-impacting change” triggers (new external integration, new data store, new admin path, changes to identity provider, network segmentation changes).
• Add an architecture update check to the change ticket template.
• Require the SSP owner to sign off that the functional architecture is updated (or not impacted) before change closure.

Evidence: Change records showing the architecture check and any updated diagrams.

5) Operationalize review and publication

• Store artifacts in a controlled repository (GRC tool, document management system, or secured version control).
• Version the diagrams and narrative; keep prior versions for audit trail.
• Ensure the SSP references the exact version (or repository location) used for the authorization package.

Where Daydream fits: If you already track controls, owners, and evidence in Daydream, map PL-2(2) to a named owner, attach the canonical architecture artifacts, and schedule recurring evidence collection so the control does not degrade between assessments.

Required evidence and artifacts to retain

Keep evidence that proves both design (architecture exists) and operation (it is maintained):

Core artifacts

• Functional architecture narrative (system functions, components, interfaces, boundaries)
• Functional decomposition table (function → component mapping)
• Logical component diagram
• Data flow diagram(s) for in-scope data
• Trust boundary/interface diagram or boundary annotations
• SSP references to these artifacts (or embedded excerpts) ²

Operational artifacts

• Version history (document revisions or repository tags)
• Change tickets showing architecture impact assessment and updates
• Architecture review approvals (security + engineering)
• Exception record if a diagram cannot be updated immediately, with compensating steps and a due date you track internally

Common exam/audit questions and hangups

Expect these questions from assessors or internal audit:

1. “Show me your system boundary and trust boundaries.”
   Hangup: boundaries exist only in words, not in diagrams.

2. “Where does authentication happen and where do admin actions occur?”
   Hangup: identity provider, PAM, and break-glass paths are omitted.

3. “Where does sensitive data enter, get stored, and leave?”
   Hangup: teams show storage but not egress paths or third party sharing.

4. “Which components are third party managed services, and what controls are inherited?”
   Hangup: architecture doesn’t label shared responsibility, so inheritance claims look speculative.

5. “Prove the diagram is current.”
   Hangup: no versioning, no linkage to change management, no review cadence evidence.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating PL-2(2) as “upload a diagram”	A single diagram rarely explains functions, flows, and boundaries	Produce a small package: functions + components + flows + boundaries
Over-scoping diagrams with every subnet and port	Reviewers can’t see the security-relevant story	Keep it logical; add an appendix only if needed
Ignoring SaaS/third party components	Data moves through them; controls may be shared	Label third party services and interfaces explicitly
No linkage to SSP controls	Architecture becomes decorative	Add a mapping table and reference architecture in SSP narratives
Stale artifacts	Common finding pattern	Put architecture updates into change control with evidence

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, so this page does not list enforcement examples.

Risk-wise, weak functional architecture increases the chance of:

• Incorrect system boundary scoping (controls applied to the wrong components)
• Missed external interfaces and data egress paths (common sources of incident exposure)
• Unverifiable control inheritance claims from cloud/third party services
  These issues typically surface during authorization, annual assessments, or after an incident, when you need to explain how the system works under time pressure. ²

A practical execution plan (phased)

Use phases rather than calendar-day promises. The goal is fast minimum compliance, then durability.

Immediate phase: get to “assessor-readable”

• Confirm the in-scope system boundary (SSP anchor).
• Draft functional decomposition (functions → components).
• Produce a clean logical component diagram and one primary data flow diagram.
• Mark trust boundaries and external interfaces.
• Store artifacts in a controlled repository and reference them in the SSP. ²

Near-term phase: make it defensible and testable

• Add secondary data flows for the highest-risk data types and admin paths.
• Build the mapping table to SSP control narratives (where the architecture supports AC/IA/SC/AU statements).
• Run a tabletop walkthrough with engineering + security: “trace a user request,” “trace an admin action,” “trace a log event.”

Ongoing phase: keep it current

• Add architecture impact prompts to change tickets.
• Require architecture version updates for material system changes.
• Periodically revalidate third party dependencies, inherited controls, and interface inventory as part of control monitoring.

Frequently Asked Questions

What’s the difference between a “functional architecture” and a network diagram?

Functional architecture explains system functions, components responsible for those functions, key data flows, and trust boundaries. A network diagram often focuses on topology and subnets and can miss identity, SaaS dependencies, and control points. ²

Do I need multiple diagrams to meet pl-2(2): functional architecture requirement?

You need enough views to make functions, flows, and boundaries unambiguous. Many teams meet this with a small package: component diagram, data flow diagram, and a short function-to-component mapping table. ¹

How do I handle third party/SaaS services in the architecture?

Include them when they provide system functions or handle in-scope data, and clearly label the interface and boundary crossing. Then document what controls are inherited versus implemented by you in the SSP. ²

How current does the architecture need to be?

Current enough that it matches production and can support your SSP control statements during an assessment. The practical standard is to update the architecture as part of change management for architecture-impacting changes and keep version history as evidence.

Who should approve the functional architecture artifact?

Security should confirm boundaries and control points, and engineering/architecture should confirm technical accuracy. Approval evidence can be lightweight (ticket approval, document sign-off) as long as it’s traceable.

What’s the fastest way to fail PL-2(2) during an assessment?

Present an architecture artifact that doesn’t match the environment or that omits major external interfaces and third party dependencies. Assessors will then question your boundary, inheritance claims, and the credibility of multiple SSP control narratives.

Footnotes

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

2. NIST SP 800-53 Rev. 5