NIST SP 800-53 Rev 5 binds US federal systems, and reaches other organizations through contracts and flow down clauses. For everyone else it is a reference catalog: a detailed, public description of what a control can look like. PL-8, Security and Privacy Architectures, asks you to develop architectures for the system that describe how confidentiality, integrity, and availability are protected, and how personally identifiable information processing is approached to minimize privacy risk. The architectures must show how they fit the enterprise architecture and describe assumptions about, and dependencies on, external systems and services. You then review and update them as the enterprise architecture changes and reflect planned changes in the security and privacy plans, concept of operations, criticality analysis, organizational procedures, and procurements.
The guidance ties system level architectures to the organization wide architectures described in PM-7. It says they include an architectural description, allocation of security functionality and controls, information about external interfaces and data exchanged across them, and the protection each needs.
What it means in practice
This is the picture that explains why the system is built the way it is. Where trust boundaries sit. Where authentication happens. Where encryption starts and ends. What the system depends on that you do not run.
That last point is where software teams feel it most. Dependencies and external services are part of the architecture. A diagram that omits your open source packages and your third party APIs leaves out a large part of the attack surface.
Evidence to collect
- Architecture diagrams with trust boundaries and data flows.
- A control allocation table: which component enforces which control.
- A list of external interfaces and dependencies, including software components.
- Review records after architecture changes.
- Links between the architecture, the system plan, and procurement or design records.
Common gaps
- Diagrams drawn for a slide deck, with no controls on them.
- External dependencies missing, including libraries and managed services.
- Privacy handling described nowhere.
- Architecture changes that never reach the plan.
How to implement it
Draw one diagram per system with trust boundaries, then annotate the controls. Keep a table of dependencies and their owners. Generate the software part from a build artifact so it stays current.
The record lists two enhancements: PL-8.1 Defense in Depth and PL-8.2 Supplier Diversity. Defense in depth asks you to say where controls are layered and how the layers are independent. Supplier diversity is relevant when a single vendor failure would hurt you.
Add architecture review to your change process. A new external service or a new data type should trigger an update.
Try it yourself
You can list the software dependencies for a repository with the free in-browser scan at gold.safeguard.sh/scan. Use the result as the software dependency section of your architecture record. The demo below shows asset discovery in the same spirit.
Click through it at your own pace, or open it full screen.
Quick check
What belongs in the dependency list?
Anything the system relies on that someone else runs or wrote: libraries, managed services, APIs, and hosting.
