SA-5(4): Low-level Design

SA-5(4) Low-level Design requires you to produce and maintain detailed, component-level system designs that are traceable to requirements and usable for secure implementation, testing, and change control. Operationalize it by standardizing what “low-level design” means for your environment, requiring it at defined SDLC gates, and retaining a consistent evidence bundle for auditors and assessors. ¹

Key takeaways:

• Define a low-level design (LLD) standard that is specific enough to build and test from, not just a high-level diagram.
• Make LLD a gated SDLC deliverable tied to change triggers (new services, major changes, security-impacting modifications).
• Keep traceability (requirements → design elements → tests) and prove the control runs with approvals, version history, and review records.

SA-5(4) sits in the System and Services Acquisition (SA) family and is usually evaluated during assessments where you must show repeatable engineering governance, not just security policy. The practical test is simple: can a reviewer pick a meaningful system component (an API, authentication service, data pipeline, infrastructure module) and see a buildable low-level design that maps back to requirements and supports secure implementation and verification?

For compliance leadership, the fastest way to make SA-5(4) real is to treat low-level design as a controlled artifact with (1) a clear definition, (2) required content, (3) ownership, (4) review/approval steps, and (5) retention and traceability rules. Many teams fail this control because their “design” lives in tribal knowledge, scattered diagrams, or tickets that do not show security-relevant details (data flows, trust boundaries, error handling, crypto choices, access control decisions).

This page gives requirement-level implementation guidance you can hand to engineering managers and auditors: what to produce, when to produce it, what evidence to store, and the exam questions you should be ready to answer. ²

Regulatory text

Control reference: SA-5(4): Low-level Design.
Provided excerpt: “NIST SP 800-53 control SA-5.4.” ¹

What the operator must do

Because the excerpt provided here does not include the full narrative, operationalize SA-5(4) as a requirement to develop, review, approve, and maintain low-level design documentation for system components at a level of detail sufficient to:

• implement the component consistently,
• evaluate security impacts before changes,
• support verification (testability) and ongoing maintenance,
• demonstrate traceability between requirements and the design. ¹

Practically, auditors and customer assessors will look for evidence that low-level design is not optional, not ad hoc, and not purely informal.

Plain-English interpretation

You need “build-ready” designs for meaningful parts of the system. A low-level design (LLD) is the specification engineers use to implement a component without guessing about security-relevant details. It is more detailed than architecture diagrams and more durable than a backlog ticket.

A compliant LLD answers questions like:

• What are the inputs/outputs, interfaces, and dependencies?
• What authentication/authorization happens where, and what are the failure modes?
• What data is stored/transmitted, and how is it protected?
• What logging and monitoring is expected?
• What configuration and secrets are required, and how are they managed?
• What tests prove the design works and meets requirements?

Who it applies to

Entity scope

SA-5(4) commonly applies to:

• Federal information systems and the organizations operating them.
• Contractors handling federal data (for example, systems supporting federal programs or subject to federal security requirements). ¹

Operational scope (where it shows up day-to-day)

You should apply SA-5(4) to:

• New system builds and major feature work.
• Security-impacting changes (identity, access control, network exposure, cryptography, logging, data storage/processing).
• High-risk components (authN/authZ services, key management, payment flows, integrations with third parties, data pipelines, administrative functions).
• Infrastructure-as-code modules and platform components where misconfiguration can become a security issue.

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

Step 1: Set an LLD standard your engineers will follow

Create an LLD template (a real template, not a one-page policy). Minimum sections that work in practice:

• Component overview: purpose, boundaries, owners, dependencies.
• Interfaces: endpoints, message formats, ports, expected callers, contracts.
• Data handling: data classification, storage locations, retention behavior, encryption expectations.
• Trust boundaries & access control: where authN/authZ occurs, roles/permissions, service-to-service authorization.
• Error handling & abuse cases: rate limiting, retries, validation, failure states, safe defaults.
• Logging/monitoring: security events, audit logs, alerting hooks.
• Threats and design mitigations: link to threat model if you have one; otherwise capture key threats and decisions.
• Testability: required tests and acceptance criteria tied to requirements.

Make the template easy to complete in your existing tooling (Markdown in Git, an internal docs platform, or a ticketing system with a required attachment). The point is consistent capture and review.

Step 2: Define trigger events (when LLD is required)

Write down objective triggers so teams cannot “interpret” their way out:

• New component/service/module.
• Material change to data flow, identity, authorization, network exposure, crypto, or logging.
• Major refactor that changes behavior, dependencies, or failure modes.

Record triggers in your SDLC policy and your change management procedure so SA-5(4) is naturally checked during delivery, not after the fact.

Step 3: Assign ownership and approvals

Set clear RACI:

• Owner: engineering manager or tech lead for the component.
• Reviewers: security engineering (for security-impacting components), platform/infrastructure owner (for infra modules), privacy or data governance where applicable.
• Approver: defined role (for example, engineering lead plus security sign-off for higher-risk changes).

Avoid “committee approvals.” One accountable approver plus required reviewers is easier to run and easier to audit.

Step 4: Build traceability from requirements to design

Pick a traceability mechanism that fits your delivery style:

• Requirement IDs in the LLD (security requirements, functional requirements).
• Links from LLD sections to user stories/epics and to security requirements.
• Links from LLD to test cases (unit/integration/security tests).

Auditors usually accept lightweight traceability if it is consistent and demonstrable.

Step 5: Bake LLD into SDLC gates

Common gates that work:

• Design review gate: LLD required before implementation starts for high-risk components.
• Pre-merge or pre-release gate: LLD must be present and approved before deployment of certain change types.
• Change advisory process: if you run CAB or formal change reviews, require LLD as an input for scoped change categories.

If you already use CI/CD checks, require a link to the LLD in the pull request template for scoped repos or folders.

Step 6: Define the minimum evidence bundle and retention location

Your evidence must survive staff turnover and tool migrations. Standardize:

• Where LLDs live (repo path, docs space, controlled system).
• Naming/versioning rules.
• Approval records (PR approvals, doc workflow approvals, meeting minutes with decision log).
• Retention expectations aligned to your broader record retention program.

A practical pattern is a “control card” that states: objective, owner, cadence/trigger, steps, and evidence bundle. Many teams track this in a GRC system or in a structured wiki page. Daydream can store the control card, map it to systems, and attach the recurring evidence bundle so you can answer audits without scrambling.

Step 7: Run control health checks and close gaps

Add an operational check that proves SA-5(4) runs:

• Periodic sampling: pick a set of recent changes and confirm an approved LLD exists when triggers applied.
• Track findings: missing LLD, missing approvals, outdated LLD, broken links, missing security sections.
• Remediate with due dates and validated closure.

This is the difference between “we have a template” and “the control operates.”

Required evidence and artifacts to retain

Use this as your audit-ready checklist:

Core artifacts

• LLD documents for in-scope components, with version history.
• Design review records (approvals, comments, decision log).
• Traceability links from requirements to design elements and to tests.
• Change records that show the LLD was required and present for scoped changes.

Supporting artifacts (commonly requested)

• LLD template/standard and the policy/procedure that defines triggers and approvals.
• System inventory or component list showing what is in scope.
• Exception records where LLD was waived (with risk acceptance and compensating controls).

Common exam/audit questions and hangups

Auditors and 3PAOs tend to probe in predictable ways:

1. “Show me low-level design for a recently changed component.”
   Hangup: the design exists only as a diagram with no security details.

2. “How do you decide when an LLD is required?”
   Hangup: triggers are informal; teams apply them inconsistently.

3. “Who approves the design, and where is that recorded?”
   Hangup: approvals happened in chat or a meeting with no minutes.

4. “How do you ensure LLD stays current?”
   Hangup: the LLD is created once and never updated after refactors.

5. “How does the design map to requirements and testing?”
   Hangup: no traceability; tests exist but are not tied to design/requirements.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating architecture diagrams as LLD	Diagrams rarely capture detailed security behavior, error cases, and testability	Require interface specs, access control decisions, data handling, and test mapping in the LLD template
“LLD required” but no triggers	Teams skip it under delivery pressure	Define explicit trigger events in SDLC and change procedures
Approvals in Slack	Not auditable; hard to prove reviewer competency and decision history	Require approval in a system of record (PR, doc workflow, ticket)
LLD created after build	Becomes a narrative, not a design; misses early risk identification	Gate implementation for high-risk changes on an approved LLD
No exception process	Teams invent “emergencies”	Create a short exception workflow with risk acceptance and retroactive design capture

Enforcement context and risk implications

No public enforcement cases are provided in the source catalog for SA-5(4), so you should treat the risk as assessment failure, customer diligence failure, and preventable security defects rather than a control tied to a specific published penalty event in this dataset. ¹

Operationally, weak LLD discipline correlates with:

• insecure defaults and inconsistent access control implementations,
• brittle incident response because engineers cannot quickly reason about component behavior,
• change-related outages and security regressions,
• audit findings for inadequate SDLC governance.

Practical 30/60/90-day execution plan

First 30 days (establish the minimum viable control)

• Name an SA-5(4) control owner and define in-scope systems/components.
• Publish an LLD template with mandatory sections (interfaces, data handling, authZ/authN, logging, threats/mitigations, tests).
• Define trigger events and embed them in your SDLC and change intake process.
• Pick the system of record for LLD storage and approvals (repo/docs/ticketing).
• Backfill LLDs for a small set of critical components to prove the template works.

Days 31–60 (make it run without heroics)

• Implement design review workflow (required reviewers and approver roles by component risk).
• Add PR or change-request checks requiring an LLD link for scoped change types.
• Create the minimum evidence bundle checklist and a central evidence register (Daydream works well for this because it keeps control cards, ownership, and evidence in one place).
• Train engineering leads on “what good looks like” using two example LLDs: one service, one infra module.

Days 61–90 (prove operating effectiveness)

• Run a control health check: sample recent changes and verify triggers, LLD presence, and approvals.
• Open remediation items for gaps, track to closure, and document exceptions properly.
• Add an LLD currency check for components with frequent change (for example, require an LLD update when interface contracts change).
• Prepare your audit package: template, procedure, sample LLDs, approval records, traceability examples, and sampling results.

Frequently Asked Questions

What qualifies as “low-level” design versus high-level architecture?

Low-level design is build-ready for a specific component: interfaces, data handling, access control decisions, failure modes, and tests. High-level architecture explains the system shape and major subsystems but usually lacks implementation details needed for secure execution. ¹

Do we need an LLD for every tiny code change?

No. Make LLD mandatory for defined triggers such as new components and security-impacting changes. Keep the triggers written and enforceable so teams apply them consistently. ¹

Can our backlog tickets count as the LLD?

Sometimes, if the ticket consistently includes the required LLD sections and has recorded review/approval. In practice, most ticket formats drift, so a controlled doc in a repo or docs platform is easier to standardize and audit.

How do we prove approvals and reviews in an audit?

Use a system of record that captures identity, timestamp, and comments (PR approvals, doc workflow approvals, or ticket approvals). Export or snapshot the approval trail into your evidence bundle for the assessed period.

What if we have a production emergency and can’t do an LLD first?

Use an exception path: approve the emergency change, then require a retroactive LLD update and a short post-implementation review that captures security impact, decisions, and follow-up tasks.

How should we handle third-party components or SaaS where we can’t design internals?

Document what you control: integration design, configuration, data flows, access control, logging, and failure modes. Treat the third party as a dependency and specify how you validate security requirements at the integration boundary.

Footnotes

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

2. NIST SP 800-53 Rev. 5