SA-5(4): Low-level Design

SA-5(4): Low-level Design requires you to produce and maintain detailed, implementation-ready designs that show how your system’s components are built and interact, so engineers can implement securely and assessors can verify controls. Operationalize it by standardizing a low-level design (LLD) template, making LLD a gated deliverable for changes, and retaining traceable evidence from design through implementation. ¹

Key takeaways:

• Define what “low-level design” means for your environment (services, data flows, trust boundaries, control hooks) and document it consistently.
• Make LLD mandatory for material system changes, and tie approvals to security and architecture review.
• Keep a tight evidence bundle: LLD document, review/approval records, traceability to requirements, and implemented configuration references.

A control can be “true” in policy and still fail in an audit if you cannot show how engineering translated requirements into buildable designs. The sa-5(4): low-level design requirement is the bridge between high-level architecture and the actual implementation details that matter for security: which components exist, how they authenticate, how data moves, which ports and protocols are allowed, where encryption terminates, and where logging and monitoring are enforced.

For a Compliance Officer, CCO, or GRC lead, the practical goal is simple: you need a repeatable mechanism to produce low-level designs for the systems in scope, and you need those designs to be reviewable, approved, and traceable to implementation. That means you treat LLD as a controlled artifact, not a one-off diagram living in an engineer’s notebook.

This page gives you requirement-level implementation guidance: who owns it, where it fits in SDLC and change management, what evidence auditors ask for, and how to roll it out quickly without boiling the ocean. Control language is from NIST SP 800-53 Rev. 5. ²

Regulatory text

Control: “NIST SP 800-53 control SA-5.4.” ¹

What the operator must do: Treat SA-5(4) as a documentation and governance requirement: produce low-level design artifacts that are sufficiently detailed to guide implementation and verification. In practice, that means you (1) define a standard for what LLD must include, (2) require it for in-scope systems and material changes, (3) route it through security/architecture review, and (4) retain it as evidence tied to the implemented system. ¹

Practical framing for audits: “Show me the document that describes how this system is built at the component level, and prove it was reviewed before deployment.”

Plain-English interpretation (what SA-5(4) is really asking)

Low-level design is the “build sheet” for security and operations. A high-level architecture diagram might show “Web app → API → Database.” An LLD answers the questions that drive real risk:

• What are the concrete services/components (names, repositories, runtime environments)?
• What identities exist (service accounts, roles), and how do they authenticate?
• What are the trust boundaries and allowed network paths (ports/protocols)?
• Where are secrets stored and rotated?
• What logs are produced, where do they go, and what alerts exist?
• What security controls are enforced by design (WAF rules, mTLS, encryption endpoints, input validation layers)?

Your job in GRC is not to write the design. Your job is to require it, standardize it, and make it auditable.

Who it applies to

Entities:

• Federal information systems and programs using NIST SP 800-53 as the control baseline. ²
• Contractors and service providers handling federal data where the contract, ATO boundary, or customer security requirements flow down NIST controls. ²

Operational contexts where SA-5(4) shows up fast:

• New system onboarding into an ATO boundary or inherited control set.
• Major releases: new authentication mechanism, new datastore, new integration, or new hosting pattern.
• “Lift-and-shift” migrations (on-prem to cloud), especially where network boundaries and identity change.
• Third-party integrations (IdP, payments, messaging) where data flows and authentication paths must be explicit.

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

Step 1: Define the LLD standard for your org

Create an LLD template and completion criteria. Keep it opinionated and short enough that teams will use it.

Minimum LLD sections (practical baseline):

1. Scope & system boundary: what is in/out, environment names, and dependencies.
2. Component inventory: service name, purpose, owner, repo link, runtime, and deployment unit.
3. Data flows: inputs/outputs, data classification, storage locations, and transfer mechanisms.
4. Trust boundaries & network paths: ingress/egress points, security groups/firewall rules, ports/protocols.
5. Identity & access design: authN/authZ model, service-to-service identity, role mappings, break-glass access.
6. Cryptography design: where encryption occurs, key management service, certificate handling.
7. Secrets management: storage, access patterns, rotation ownership.
8. Logging/monitoring hooks: audit logs, security logs, retention target, alerting ownership.
9. Failure modes & resilience (as needed): error handling, retries, rate limits, dependency timeouts.
10. Implementation traceability: links to IaC modules, config files, and tickets/epics.

Operator tip: If your teams already produce ADRs (architecture decision records), keep ADRs separate. LLD is about “what we built” at detail level, not “why we chose it.”

Step 2: Assign ownership and workflow

Create a requirement control card so the organization can answer: who owns SA-5(4), what triggers it, how it’s executed, and how exceptions work. This is a recommended operational control. ¹

Recommended RACI (adapt as needed):

• Owner (Accountable): Head of Architecture, Engineering Enablement, or Product Security (pick one).
• Responsible: System/service engineering leads.
• Consulted: Security engineering, privacy (if sensitive data), platform/cloud team.
• Informed: Compliance/GRC, internal audit, program leadership.

Step 3: Make LLD a gate in SDLC and change management

This is where most programs fail: they write a template but don’t enforce it.

Define trigger events that require an LLD update and review:

• New system in scope.
• Any material change to: auth, network exposure, data stores, encryption, secrets, logging, or third-party integrations.
• Any change that alters the system boundary for ATO or SSP purposes.

Embed the gate:

• Add an LLD requirement to your change request template (or PRD/epic definition of ready).
• Require security/architecture approval before deployment for triggered changes.
• If you use CI/CD, add a “design artifact present” check at the ticket/epic level (not as a brittle pipeline step).

Step 4: Define the minimum evidence bundle (what you retain)

Define the evidence bundle per execution cycle so audits don’t become scavenger hunts. This is a recommended operational control. ¹

Evidence bundle checklist (store centrally):

• Approved LLD document (versioned) with author and date.
• Review records: architecture review notes, security review comments, approval timestamps.
• Traceability: mapping from LLD to implementation items (tickets, IaC modules, configuration references).
• Exception records (if any): what was waived, who approved, compensating controls, and expiration.
• “As-built validation” note: lightweight confirmation that implementation matches LLD (for example, a post-deploy checklist or peer review outcome).

Retention: Follow your program’s retention rules. For audit readiness, keep superseded versions when the design changes materially so you can show what was in effect at a point in time.

Step 5: Run recurring control health checks

Add periodic checks to prove sustained operation: sample recent changes and confirm an LLD exists, was reviewed, and matches reality. Track remediation items to closure with owners and due dates. This is a recommended operational control. ¹

A practical health-check method:

• Pull a list of recent production changes (from change management or release tags).
• Sample items that match trigger criteria.
• Verify: LLD updated, approvals present, and key controls reflected (auth, network, logging, secrets).
• Create remediation tickets for gaps; require closure evidence.

Required evidence and artifacts to retain (audit-ready list)

Use this as your “ask” to engineering and architecture:

Artifact	What auditors look for	Where it usually lives
LLD template/standard	Consistency and completeness criteria	Security/architecture standards repo or GRC library
LLD per in-scope system/service	Component-level details, current state	Engineering docs (versioned) linked from CMDB/service catalog
Review & approval evidence	Security/architecture sign-off before implementation	Ticketing system, pull request reviews, architecture review board minutes
Traceability links	Clear path from requirements/design to build	Epics, change records, IaC repos
Exceptions & compensating controls	Governance, time-bounded waivers	Risk register or exception tracker
Control health check logs	Ongoing operation and remediation	GRC workflow tool, audit log folder

Common exam/audit questions and hangups

Questions you should be ready to answer quickly:

• “Show me the low-level design for System X and the date it was last updated.”
• “What events trigger an update to the low-level design?”
• “Who approves the design before deployment?”
• “How do you ensure the design matches the production implementation?”
• “How do third-party services appear in your design (data flows, auth paths, logging)?”

Hangups that slow audits:

• LLD exists but is not version-controlled; no one can prove what was approved.
• LLD describes an ideal state; production drift is obvious from configs and logs.
• Teams treat LLD as optional for “small changes,” but the small change altered exposure (new endpoint, new role, new integration).

Frequent implementation mistakes (and how to avoid them)

1. Mistake: confusing HLD for LLD.
   Fix: Require concrete fields: ports/protocols, identities, encryption endpoints, logging destinations, and exact components.

2. Mistake: no explicit trigger events.
   Fix: Write triggers into your change process. If the change touches auth, network, data store, secrets, logging, or third-party integration, LLD is mandatory.

3. Mistake: approvals happen after deployment.
   Fix: Tie approval to the release gate or change record state. “Approved” must exist before “implemented.”

4. Mistake: evidence scattered across tools.
   Fix: Define a minimum evidence bundle and a single retention location with links out to source systems. ¹

5. Mistake: “document once” and never revisit.
   Fix: Add control health checks and sample testing so you can show continued operation. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-5(4). ¹

Practical risk is still real:

• ATO and customer assessment risk: Lack of LLD weakens your ability to justify control implementation and system boundary decisions.
• Incident response risk: During an incident, teams lose time reconstructing “how it works” from tribal knowledge and configs.
• Third-party dependency risk: If integrations are not captured in LLD, data flows and authentication paths become blind spots for vendor/third-party due diligence.

Practical 30/60/90-day execution plan

First 30 days: Stand up the requirement and the gate

• Publish an LLD standard and template with completion criteria.
• Create the SA-5(4) control card: owner, triggers, workflow, exception path. ¹
• Pick a retention location and naming convention (system/service + version/date).
• Pilot with one high-change system and one stable system; refine template based on engineer feedback.

Days 31–60: Operationalize across in-scope systems

• Add LLD checks to change intake (ticket templates, CAB checklist, release readiness).
• Train reviewers (security/architecture) on what “good” looks like; publish examples.
• Backfill LLDs for highest-risk systems first (internet-facing, sensitive data, complex third-party integrations).
• Define the minimum evidence bundle and roll it into your audit evidence map. ¹

Days 61–90: Prove sustained operation and close gaps

• Run the first control health check: sample recent changes, validate evidence, open remediation items. ¹
• Establish an exception review cadence (time-bound waivers with compensating controls).
• Tie LLD references into your SSP/ATO package artifacts where applicable.
• If you need a workflow system to reduce manual follow-up, Daydream can track ownership, trigger events, evidence bundles, and recurring health checks so SA-5(4) stays operational instead of becoming a documentation scramble. ¹

Frequently Asked Questions

What counts as “low-level design” for SA-5(4)?

A document that lets an engineer implement the system and lets an assessor verify key control hooks: components, identities, trust boundaries, data flows, encryption points, logging, and configuration references. A single high-level diagram rarely meets that bar by itself.

Do we need an LLD for every microservice?

Require LLD where it reduces risk and audit friction: externally exposed services, services handling sensitive data, and core shared services. For very small internal services, a lightweight LLD section in the repo may be enough if it covers the required fields and is reviewed.

How do we keep LLDs from becoming stale?

Put explicit trigger events in change management and run periodic control health checks that sample real changes against required evidence. If teams can deploy without updating LLD, it will drift.

Where should LLD live: GRC tool or engineering docs?

Keep the LLD where engineers will maintain it (version-controlled docs or an internal wiki with versioning), then store links and approvals in your audit evidence map. The key is traceability and retention, not the specific platform.

What’s the minimum approval standard auditors expect?

A documented reviewer with appropriate authority (architecture and/or security) and a timestamped approval that occurred before implementation for changes that trigger the requirement. Informal “looks good” chats are hard to defend without records.

How do third-party services fit into the LLD?

Treat third parties as explicit components in the data flow and identity design: what data is sent, how it’s authenticated, what network paths exist, and what logs/alerts cover the interaction. This is a common gap during diligence and assessments.

Footnotes

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

2. NIST SP 800-53 Rev. 5