SA-17(5): Conceptually Simple Design

The sa-17(5): conceptually simple design requirement sits in the NIST SP 800-53 System and Services Acquisition (SA) family and is meant to reduce security risk by reducing design complexity. Complexity is an attack surface multiplier: more moving parts, more implicit trust, more hidden pathways, and more ways for controls to be misapplied. For a Compliance Officer, CCO, or GRC lead, the practical challenge is that “simplicity” can sound subjective unless you translate it into enforceable engineering standards and repeatable review steps.

This requirement is also easy to “paper comply” with if you only write a policy statement. Assessors typically look for objective signals that the organization demands simple designs and makes tradeoffs explicit: decision records, documented architectures, threat models tied to design choices, and a consistent exception process when complexity is unavoidable. The fastest path to operationalization is to treat SA-17(5) like a product requirement: define it, test it, and retain proof that you tested it.

Primary sources: NIST SP 800-53 Rev. 5 control catalog content and the Rev. 5 publication landing page. ^{1 2}

Regulatory text

Excerpt (as provided): “Require the developer of the system, system component, or system service to:” ¹

Operator interpretation: SA-17(5) is a “push-down” requirement. You must ensure the party building the system (internal engineering or an external third party) is explicitly required to follow conceptually simple design principles, and you must be able to show how you enforced that requirement through your acquisition and development lifecycle. ¹

What the operator must do:

• Translate “conceptually simple design” into clear design constraints and review criteria your developers can follow.
• Make those constraints binding (SDLC gates, statements of work, acceptance criteria).
• Collect evidence that designs were reviewed against those criteria and that exceptions were approved with risk acceptance. ¹

Plain-English interpretation (what “conceptually simple” means in practice)

A conceptually simple design is one that a qualified reviewer can understand, reason about, and test without relying on hidden coupling or undocumented assumptions. In practice, “simple” usually means:

• Clear trust boundaries (what is trusted, what is not, and why).
• Few and well-defined interfaces (APIs, message topics, integrations).
• Minimal privilege and minimal shared state (avoid “god services,” shared admin accounts, or broad cross-service credentials).
• Predictable failure modes (errors fail closed where appropriate, and recovery paths are understood).
• Documented design decisions (why this architecture was chosen, and why complexity is acceptable when it exists).

This is not a mandate to avoid modern architectures. It is a mandate to prevent accidental complexity from becoming permanent risk.

Who it applies to

Entities:

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

Operational contexts where SA-17(5) shows up:

• New application development and major refactors.
• Procurement of SaaS, managed services, and system components where you rely on a third party’s engineering decisions.
• Security architecture reviews and ATO or continuous monitoring activities.
• High-change environments (microservices, event-driven systems, extensive CI/CD) where complexity accumulates quickly.

If you cannot impose requirements on a third party’s internal design, you can still require and verify design transparency (diagrams, interface specs, dependency maps, security architecture) as a condition of onboarding and renewal.

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

Step 1: Assign ownership and scope the “developer” population

1. Name a control owner (often Security Architecture, AppSec, or Engineering Enablement) and a compliance owner (GRC).
2. Define who counts as “developer” in your environment:
   • Internal software teams.
   • System integrators.
   • SaaS providers (as applicable to integration and configuration design).
   • Component suppliers (libraries, containers, infrastructure modules).

Deliverable: SA-17(5) control implementation statement mapped to owners, procedures, and recurring evidence artifacts. ¹

Step 2: Define “conceptually simple” as enforceable design rules

Create a one-page standard that engineering can follow and reviewers can test. Keep it tight. Example rules:

• Each service has a single primary responsibility and documented upstream/downstream dependencies.
• Every integration has an owner, an interface contract, and an authentication/authorization model.
• Privileged actions require explicit, logged workflows (no hidden admin endpoints).
• Secrets and identities are scoped per service/environment; no shared long-lived credentials.
• Data flows and trust boundaries are diagrammed for material systems.

Deliverable: Secure design standard (or architecture standard) with a “conceptual simplicity” section and a defined exception process.

Step 3: Embed the requirement into SDLC gates (internal builds)

Add an explicit checkpoint to the lifecycle:

• Architecture review gate: reviewer validates boundary diagrams, dependency mapping, and privilege model against the simplicity rules.
• Threat modeling gate (where used): confirm threats align to the defined boundaries and interfaces.
• Pre-production approval: confirm high-risk complexity items have compensating controls and documented acceptance.

Evidence: Completed design review checklist, meeting notes/approvals, and updated diagrams stored in the system of record.

Step 4: Embed the requirement into third-party onboarding and contracts

For third parties that build or operate components for you:

• Add contract/SOW language requiring:
  • Architecture documentation (system context, data flows, and trust boundaries).
  • Interface inventory (APIs, admin consoles, integrations).
  • Material dependency list (critical sub-processors, hosted components, key libraries where applicable).
  • A documented approach to minimizing complexity (design principles and review practices).
• Make delivery of these artifacts an acceptance criterion for go-live and renewals.

Evidence: Contract clauses, SOW requirements, third-party design packet, and your review/approval record.

Step 5: Run an exception process that does not become a loophole

Some complexity is justified. Treat it like risk:

• Record what is complex (e.g., multiple identity providers, multi-region failover, shared message bus).
• State why it exists.
• Document compensating controls (monitoring, segmentation, least privilege, additional testing).
• Get explicit approval from the right authority (Security Architecture + system owner, with GRC visibility).

Evidence: Exception register entries with approvals and review cadence.

Step 6: Make it auditable (and repeatable)

Build a recurring evidence routine:

• For each in-scope system: keep current diagrams, ADRs, interface inventories, and the latest design review.
• For each third party: retain the latest design packet and the review outcome.
• Track findings to closure like any other security issue.

How Daydream fits naturally: Daydream can keep SA-17(5) mapped to a control owner, a concrete procedure, and a recurring evidence checklist so you can pull an audit-ready packet per system or third party without rebuilding the story each cycle. ¹

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

Keep these artifacts in a controlled repository with versioning:

• SA-17(5) control implementation statement (owner, scope, frequency of review). ¹
• Secure design/architecture standard including “conceptual simplicity” criteria.
• System architecture diagrams:
  • Context diagram
  • Data flow diagram
  • Trust boundary diagram
• Interface inventory (APIs, integrations, admin paths).
• Architecture Decision Records (ADRs) for major design choices that add complexity.
• Design review checklist results and approvals.
• Exception register with risk acceptance and compensating controls.
• For third parties: contract/SOW clauses and delivered design documentation plus your evaluation notes.

Common exam/audit questions and hangups

Auditors and assessors tend to probe the same weak spots:

• “Define ‘conceptually simple.’ Where is it documented?” If you cannot point to criteria, you will struggle.
• “Show me a recent system where you enforced this.” They will ask for a specific project trail: review invitation, checklist, diagrams, ADRs, sign-off.
• “How do you handle exceptions?” A vague “case-by-case” answer reads as “no control.”
• “Does this apply to third parties?” If third parties develop or operate a component, assessors expect contractual and onboarding hooks, not informal requests. ¹
• “How do you keep documentation current?” Stale diagrams undermine the claim that the design is understandable and controlled.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating simplicity as style guidance.
   Fix: Convert it into reviewable requirements (interfaces documented, boundaries defined, dependencies enumerated).

2. Mistake: Only applying it to new builds.
   Fix: Add a trigger for material changes (new integration, new identity path, major data flow change) and require a lightweight re-review.

3. Mistake: Letting microservices sprawl become “normal.”
   Fix: Require a dependency map and ownership per service; set rules for shared components, authN/Z patterns, and standard templates.

4. Mistake: No third-party deliverables.
   Fix: Add design transparency requirements to onboarding and contracts. If the third party refuses, document the risk decision and limit integration scope.

5. Mistake: Exceptions without compensating controls.
   Fix: Force an explicit “complexity tax” entry: added monitoring, segmentation, additional testing, or reduced blast radius.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat SA-17(5) primarily as an assessment and risk-reduction expectation rather than a control with a specific public penalty trail in this dataset. ¹

Risk-wise, failure modes are straightforward:

• Complex designs create review gaps, misconfigurations, and over-broad trust relationships.
• Incident response takes longer when system behavior cannot be explained quickly.
• ATO and customer assessments slow down when architecture evidence is missing or inconsistent.

Practical 30/60/90-day execution plan

First 30 days (establish the control and minimum evidence)

• Assign SA-17(5) owners and define in-scope systems and third parties.
• Draft “conceptually simple design” criteria as a short standard.
• Create a design review checklist aligned to the criteria.
• Pilot on one active project and one high-risk existing system (collect the full evidence packet).

Next 60 days (embed into SDLC and third-party motions)

• Add the checklist as an SDLC gate (architecture review or security review).
• Stand up an exception register and approval workflow.
• Update third-party onboarding to request design documentation (diagrams, interfaces, dependency list).
• Update contract templates or SOW language for applicable third parties.

By 90 days (scale, measure, and make it routine)

• Roll out to all in-scope teams and create a central repository structure for artifacts.
• Train reviewers on what “good” looks like and what fails review.
• Start a quarterly sampling review (GRC selects systems/third parties, verifies evidence is current, tracks gaps to closure).
• Configure Daydream (or your GRC system) so SA-17(5) evidence requests and reminders are automated and consistent across systems. ¹

Frequently Asked Questions

What counts as “conceptually simple” for a microservices architecture?

Microservices can meet SA-17(5) if service responsibilities, trust boundaries, and dependencies are explicit and reviewed. The evidence is the dependency map, interface contracts, and ADRs that justify any added complexity.

Does SA-17(5) require rewriting legacy systems?

It drives expectations for design discipline, not automatic rebuilds. For legacy systems, focus on documenting current boundaries and interfaces, then apply the simplicity criteria to material changes and high-risk areas first.

How do I apply SA-17(5) to a SaaS third party if I can’t see their code?

Require design transparency deliverables: architecture diagrams, interface inventory, identity model, and documented dependencies relevant to your integration. If the third party cannot provide them, document the risk decision and reduce integration scope where possible.

What evidence is “enough” for an assessor?

Provide a consistent packet per system: diagrams, interface inventory, design review checklist with sign-off, and ADRs for major complexity tradeoffs. Consistency across multiple systems often matters more than producing a perfect diagram once.

Who should approve exceptions to simplicity rules?

The system owner and a security architecture authority should approve, with GRC tracking the exception and renewal. The approver must be able to accept the operational and security tradeoffs tied to added complexity.

How do we stop this from becoming a bottleneck for engineering teams?

Keep the criteria short, standardize templates for diagrams and ADRs, and offer “pre-approved patterns” (reference architectures) that already satisfy the simplicity rules. Review time drops when teams reuse known-good patterns.

Footnotes

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

2. NIST SP 800-53 Rev. 5