03.15.01E — Security Architecture

Official NIST requirement content

Security requirement

a.Develop a security architecture for the system that:
1. a-1.Describes the security requirements and approach to be taken for protecting the confidentiality, integrity, and availability of CUI,
2. a-2.Describes how the architecture is integrated into and supports the enterprise architecture, and
3. a-3.Describes any assumptions about, and dependencies on, external systems and services.
b.Review and update the security architecture [Organization-defined: frequency] to reflect changes in the enterprise architecture.
c.Reflect planned security architecture changes in system security plans, concept of operations, criticality analysis, organizational procedures, and procurements and acquisitions.

Official NIST discussion

Discussion

The security architecture at the system level is consistent with the organization-wide security architecture, which is integral to and developed as part of the enterprise architecture. The security architecture includes an architectural description, the allocation of security functionality (i.e., safeguards and countermeasures), security-related information for external interfaces, information being exchanged across the interfaces, and the protection mechanisms associated with each interface. The architectures can also include other information, such as user roles and the access privileges assigned to each role; security requirements; types of information processed, stored, and transmitted by the system; cybersecurity supply chain risk management (CSCRM) requirements; restoration priorities of information and system services; and other protection needs.

With the use of modern computing technologies, it is becoming less common for organizations to control all information resources. There may be key dependencies on external services and service providers. Describing such dependencies as part of the security architecture is necessary for developing a comprehensive CUI protection strategy. Establishing, documenting, and maintaining a baseline configuration for organizational systems under configuration control is critical to implementing and maintaining an effective security architecture. Guidance on developing trustworthy, secure, and cyber-resilient systems using systems security engineering practices and security design concepts is provided in SP 800-160v2 .23. This requirement is sourced to a control tailored out of the SP 800-53B .13 moderate baseline in SP 800-171.

Official organization-defined parameters

Tailoring decisions required

Resolve these values through the governing organization’s approved tailoring and risk-management process before declaring the requirement implemented.

frequencyorganization-defined frequencythe frequency for reviewing and updating the security architecture to reflect changes in the enterprise architecture is defined.

Official protection strategy classifications

Protection strategies supported

These classifications are carried from the official SP 800-172 OSCAL record and help explain the enhanced requirement’s defensive purpose.

PS-PRAPenetration-Resistant Architecture

Bare Metal Cyber interpretation

Implementation perspective

Treat Security Architecture as an enhanced CUI protection outcome for elevated threat conditions that must be reflected in the system boundary, documented implementation, operational behavior, and assessment evidence. Pay particular attention to accurate plans, architecture, rules of behavior, system boundaries, and lifecycle alignment for CUI protection.

Confirm the federal agency selected this enhanced requirement for the critical program or high-value asset and identify the CUI system components, services, users, and external connections in scope.
Resolve every organization-defined parameter through an approved governance and tailoring process.
Map each clause of the requirement to an accountable owner, implementation mechanism, and evidence source.
Verify that inherited and shared implementations are supported by current provider evidence and responsibility boundaries.
Collect evidence during normal operation and review changes, exceptions, and deficiencies on a risk-based cadence.

Questions to ask

Which critical-program or high-value-asset CUI, data flows, users, and services are protected by this enhanced requirement?
Which portions are implemented locally, inherited, shared, or not applicable, and what evidence supports that determination?
Do the system security plan, deployed configuration, operating process, and assessment evidence tell the same story?
What change, incident, or threshold should trigger reassessment?

Evidence and validation

system security plans
architecture and data-flow diagrams
rules-of-behavior acknowledgments
plan review and approval records

Common failure patterns

plans copied from templates without system specificity
diagrams that do not match deployed services
inherited protection claimed without provider evidence
plans updated only before assessment

Official NIST SP 800-172A content

Assessment objectives and methods

Assessment objectives (5)

a.1.
a security architecture for the system that describes the requirements and approach to be taken for protecting the confidentiality, integrity, and availability of CUI is developed.
a.2.
a security architecture for the system that describes how the security architecture is integrated into and supports the enterprise architecture is developed.
a.3.
a security architecture for the system that describes any assumptions about and dependencies on external systems and services is developed.
b.
the security architecture is reviewed and updated [Organization-defined: frequency] to reflect changes in the enterprise architecture.
c.
planned security architecture changes are reflected in system security plans, concept of operations, criticality analyses, organizational procedures, procurements, and acquisitions.

Examine

Security planning policy
procedures addressing information security architecture development
procedures addressing information security architecture reviews and updates
enterprise architecture documentation
information security architecture documentation
system security plan
security CONOPS for the system
records of information security architecture reviews and updates
other relevant documents or records

Interview

Personnel with security planning and plan implementation responsibilities
personnel with information security responsibilities
personnel with information security architecture development responsibilities

Test

Mechanisms supporting and/or implementing the development, review, and update of the information security architecture
processes for developing, reviewing, and updating the information security architecture

Official source-control relationships

Source NIST SP 800-53 controls

These controls are referenced by the official SP 800-172 Rev. 3 OSCAL record. Open the corresponding control pages for complete control text, enhancements, D3FEND mappings, and related learning.

Source controlPL-8Open SP 800-53 control →

Source record

Authoritative sources

Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. The official publications, the responsible federal agency, and the governing contract or agreement determine applicability, tailoring, assessment depth, and required implementation.