SA-5(3): High-level Design

SA-5(3) High-level Design requires you to produce and maintain a high-level system design that is complete enough to support security engineering, control implementation, and reviewer understanding. Operationalize it by defining a standard “design package,” assigning an owner, integrating design updates into your SDLC change gates, and retaining versioned evidence that the design stays current. ¹

Key takeaways:

• Maintain a version-controlled high-level design that maps architecture decisions to security requirements and controls. ¹
• Make design updates a required step for significant changes, not a one-time document created for audits. ²
• Keep an evidence bundle: diagrams, interface inventory, data flows, trust boundaries, approvals, and change history. ³

High-level design is where most programs either become auditable or fall apart under scrutiny. SA-5(3) sits in the System and Services Acquisition (SA) family and is typically tested as “show me you understand your system well enough to secure it.” If your documentation is a pile of stale diagrams, you will struggle to defend boundary decisions, data flows, inherited controls, third-party connections, and where key security mechanisms actually live.

For a Compliance Officer, CCO, or GRC lead, the goal is not to become the chief architect. The goal is to make high-level design a repeatable compliance requirement with: (1) clear ownership, (2) a defined minimum design package, (3) required update triggers, (4) approval and exception handling, and (5) evidence that the design is used to drive security decisions. This page gives you an operator’s runbook to stand up SA-5(3) quickly, align it to your SDLC and change management, and package evidence for audits and customer diligence. ⁴

Regulatory text

Control reference: SA-5(3): High-level Design
Provided excerpt: “NIST SP 800-53 control SA-5.3.” ¹

What an operator must do (practical reading): Maintain a high-level design description for the system (or major service) that is sufficient for governance and security review. “High-level” means architecture, boundaries, major components, and key interfaces. Your design must be kept current as the system changes, and it must be reviewable by security and compliance stakeholders. ⁵

Plain-English interpretation

SA-5(3) means you can’t secure what you can’t describe. You need a durable, version-controlled description of how the system is built: what the major parts are, how data moves, where trust boundaries sit, and which internal teams and third parties connect to it. The design should be detailed enough that an independent reviewer can understand the architecture and ask meaningful security questions without reverse-engineering your environment. ¹

Who it applies to

Entity types

• Federal information systems.
• Contractor systems handling federal data. ¹

Operational context

• New system builds and major service launches.
• Material architecture changes (cloud migrations, new identity plane, new network segmentation model).
• New third-party integrations (payment processors, customer data platforms, managed service providers).
• High-impact features that introduce new data types, new users, or new trust boundaries. ²

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

1) Create a “SA-5(3) control card” (owner + trigger + runbook)

Write a one-page control card that answers:

• Objective: Maintain high-level design that supports security engineering and auditability.
• Owner: Architecture lead, engineering manager, or security architecture; name a role and a backup.
• Triggers: New system, major release, material change request, new third party connection, or boundary change.
• Cadence: Review when triggered; also do periodic health checks (tie to your governance calendar).
• Exceptions: Define when a design update can be deferred and who approves the exception.
  This directly addresses the common risk that teams can’t show ownership, operating cadence, or evidence. ¹

2) Define the minimum “high-level design package” (a standard template)

Make it a template so teams can comply quickly. Minimum sections you should require:

A. System context and boundary

• System purpose and primary users.
• System boundary statement (what’s in scope vs out of scope).
• Environment inventory (prod/stage/dev) at a descriptive level.

B. Architecture diagram(s)

• Component diagram: major services, data stores, messaging, identity components.
• Network or trust boundary diagram: zones, ingress/egress, segmentation, control points.

C. Data flow and data classification

• Key data elements handled (customer PII, auth tokens, logs).
• Data flow diagram for critical paths (ingest, processing, storage, egress).
• Where encryption is applied (in transit/at rest) at a high level.

D. Interfaces and dependencies

• API and integration inventory (internal + third party).
• Authentication/authorization model per interface (SSO, service accounts, OAuth flows).
• External services relied on (cloud services, CI/CD, monitoring).

E. Security architecture notes

• Key security controls “placed” in the design (WAF, secrets management, KMS, EDR coverage zones).
• Logging and monitoring points.
• Administrative access paths and break-glass approach.

F. Control mapping pointers

• Link to your SSP/control implementation summary, and call out inherited vs system-specific controls.
  Keep this high level; the point is traceability. ⁴

3) Put design maintenance into your SDLC and change management gates

SA-5(3) fails most often because design docs exist but don’t stay current. Add two gates:

Gate 1: Architecture review (pre-implementation)

• Require the template above for any material change request.
• Record review comments and approval.

Gate 2: Post-change validation (after implementation)

• Confirm diagrams and interface inventory match deployed reality.
• Update version and changelog.

Tie both gates to tickets in your system of record (Jira/ServiceNow/Azure DevOps). If you can’t point an auditor from a change ticket to the corresponding updated design package, you will spend cycles reconstructing history. ²

4) Make third-party connections explicit

High-level design should clearly show:

• Which third parties connect to your system.
• What data is shared.
• Where credentials/keys are stored and rotated (at a high level).
• Any network connectivity (VPN, private link, public internet, allowlists).
  This is where third-party risk management and architecture intersect: the design package becomes a durable input to due diligence, onboarding, and contract scoping. ²

5) Run recurring control health checks and track remediation to closure

Schedule a recurring health check that samples systems and verifies:

• Design package exists and is versioned.
• Last update aligns to last material change(s).
• Known exceptions have approvals and expiry dates.
• Gaps are tracked to closure with an owner and due date. ¹

How Daydream fits naturally: If you manage multiple systems and many third parties, the work breaks down on consistency and evidence retrieval. Daydream can serve as the control system of record: control cards, required evidence bundles, recurring health checks, and a single place to answer “show me the latest approved design for System X and the last change that updated it.”

Required evidence and artifacts to retain

Keep an evidence bundle per system/service in a version-controlled repository:

1. High-level design document (template-complete) with version history.
2. Architecture diagrams (exported PNG/PDF plus editable source if you have it).
3. Data flow diagrams for critical flows.
4. Interface inventory including third-party connections.
5. Trust boundary definition (diagram or written boundary statement).
6. Approval record (security/architecture sign-off, ticket link, meeting notes).
7. Change linkage (list of change tickets/releases that triggered updates).
8. Exception records (approval, scope, expiry, compensating controls).
9. Control health check results and remediation tickets. ⁴

Common exam/audit questions and hangups

Auditors and assessors tend to focus on “current, complete, and used”:

• “Show the system boundary and external connections.” They want to see what’s inside your authorization boundary and what is inherited or external. ²
• “How do you ensure the design stays current?” A static diagram with no update triggers reads as shelfware.
• “Where are key security mechanisms implemented?” Expect questions about identity, encryption, logging, admin access paths.
• “How are third parties represented in the design?” Missing third-party data flows is a recurring gap in both audits and customer reviews.
• “Prove this is operating.” They will ask for recent change examples where the design package was updated and approved. ¹

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating “high-level design” as a one-time deliverable

Fix: Make design updates a mandatory step in change management. No approved change ticket for material changes without an updated design package or approved exception.

Mistake 2: Diagrams without data flows or trust boundaries

A box-and-line chart isn’t enough if it doesn’t show where sensitive data moves and where trust changes.
Fix: Require at least one data flow diagram for critical paths and a boundary statement.

Mistake 3: No clear owner (docs rot immediately)

Fix: Assign ownership to a role that lives close to architecture decisions, and add a backup owner in case of reorgs. Document it in the control card. ¹

Mistake 4: Third-party connectivity hidden in tribal knowledge

Fix: Put third-party systems in the interface inventory and diagrams. Tie to your third-party intake workflow so new integrations can’t ship without documentation.

Mistake 5: Evidence scattered across drives and wikis

Fix: Choose one repository per system for the evidence bundle and require links from tickets. A GRC system can index and attest to evidence presence; the underlying artifacts should still live in engineering-friendly version control.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-5(3). Practically, the risk is assessment failure, delayed authorizations, and poor incident outcomes because teams can’t quickly answer: “What changed?”, “Where does this data go?”, and “Which third party receives it?” ²

A practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign control owner and backup; publish the SA-5(3) control card. ¹
• Define and approve the high-level design template and evidence bundle checklist.
• Pick the system-of-record locations (repo paths, ticket fields, approval mechanism).
• Pilot on one high-impact system and one system with multiple third-party integrations.

Next 60 days (embed into delivery)

• Add SDLC/change gates: “design update required” for material changes, with exception workflow.
• Train engineering leads and security reviewers on the template and approval expectations.
• Backfill high-level designs for prioritized systems (start with systems handling regulated data or federal data).

By 90 days (prove operation)

• Run the first control health check across a sample of systems; open remediation tickets and drive to closure. ¹
• Collect “operating effectiveness” examples: at least a few change tickets where design packages were updated, approved, and linked.
• Prepare an audit-ready package per system: design doc, diagrams, interface inventory, approvals, and changelog.

Frequently Asked Questions

What counts as “high-level” design versus detailed engineering diagrams?

High-level design describes major components, boundaries, and interfaces so a reviewer can understand security impact. Detailed implementation belongs in lower-level design docs, runbooks, or code.

Does SA-5(3) require a data flow diagram?

The provided excerpt does not list required diagrams, but assessors commonly expect you to explain how data moves across trust boundaries. Requiring at least one data flow diagram for critical paths prevents review churn. ²

How do we operationalize this in an agile team with frequent releases?

Use change triggers: only material changes require a design update. Define “material” in your control card (new data types, new third party, new auth model, boundary change) and enforce it in your change workflow.

Can a wiki page satisfy SA-5(3)?

It can, if it is versioned, access-controlled, reviewable, and tied to approvals and change history. Most teams still store diagrams and structured inventories in version control and link them from the wiki for durability.

Who should approve the high-level design package?

Security architecture (or delegated security reviewer) should approve security-relevant design changes, and an architecture/engineering owner should approve correctness. Keep approvals lightweight but recorded and link them to the triggering change ticket.

How does this connect to third-party risk management?

The design package should explicitly identify third-party integrations, shared data, and connectivity paths. That becomes a stable input to third-party onboarding, contract scope, and periodic reviews.

Footnotes

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

2. NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5 DOI

4. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON

5. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 DOI