SA-8(28): Acceptable Security

SA-8(28) requires you to apply the “acceptable security” design principle to systems you build, buy, or integrate, and to prove you did it with repeatable engineering and governance evidence. Operationalize it by defining measurable “acceptable” security thresholds, embedding them into architecture and procurement gates, and retaining design decisions that show risk-informed tradeoffs. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Define what “acceptable security” means for your mission and risk tolerance, then convert it into explicit engineering and acquisition criteria.
• Build decision checkpoints (architecture reviews, threat modeling, third-party onboarding) that confirm designs meet the threshold before release.
• Keep evidence that ties design choices to risk acceptance, requirements, and verification results, not just a policy statement.

Compliance teams struggle with SA-8(28) because it sounds subjective: “acceptable security” can be misread as “do your best” or “meet baseline controls.” Assessors typically expect something more concrete: a defined acceptance threshold for security risk and a repeatable way to prove that system designs meet that threshold before deployment and after meaningful change.

For a CCO or GRC lead, the fastest path is to treat SA-8(28) as a design-governance requirement. You set the organization’s definition of “acceptable” in operational terms (for example, required security capabilities, prohibited architectures, minimum assurance activities, and explicit risk acceptance rules). Engineering then applies that definition in system architecture, software development, and third-party selection. Finally, you retain artifacts that demonstrate decisions were made deliberately, reviewed, and verified.

This page focuses on requirement-level execution: who owns what, which process gates matter, what evidence to keep, what auditors ask, and how to avoid common “we have a policy” failures. The target keyword for this page is sa-8(28): acceptable security requirement.

Regulatory text

Requirement excerpt: “Implement the security design principle of acceptable security in {{ insert: param, sa-08.28_odp }}.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do:
You must explicitly incorporate the “acceptable security” principle into how systems are designed and acquired, not as an after-the-fact checklist. In practice, that means:

• You define security acceptability criteria (what level of security is “acceptable” for different system types and data).
• You apply those criteria during architecture and engineering decisions, including third-party products and services.
• You document the decisions and the basis for concluding the design meets your acceptability threshold.
• Where a design does not meet the threshold, you either remediate or formally accept the residual risk through an approved risk acceptance path.

NIST frames this as a security design principle under SA-8, so evidence usually lives in engineering governance (architecture standards, secure design requirements, design review records), supported by GRC risk acceptance and exceptions.

Plain-English interpretation (what “acceptable security” means)

“Acceptable security” means the system’s design reduces security risk to a level your organization has explicitly decided it can live with, given mission needs, cost, and operational constraints. This is not “perfect security.” It is “security that meets defined acceptance criteria,” with a controlled process for exceptions.

A workable interpretation for audits:

• Acceptable = defined: You can point to documented criteria (by system tier, data sensitivity, deployment environment, or authorization boundary).
• Acceptable = reviewed: Qualified reviewers (security architecture, engineering leads, product owner, and risk owner) validate designs against the criteria.
• Acceptable = evidenced: You retain proof (threat models, architecture diagrams, control selection rationale, test results, and exception approvals).

Who it applies to (entity and operational context)

SA-8(28) is commonly applied in:

• Federal information systems and programs using NIST SP 800-53 control baselines. (NIST SP 800-53 Rev. 5)
• Contractor systems handling federal data where NIST 800-53 is flowed down contractually or used to satisfy program requirements. (NIST SP 800-53 Rev. 5)

Operationally, it touches:

• System engineering and architecture (new builds, major redesigns, cloud migrations)
• SDLC and DevSecOps (security requirements and design reviews)
• Procurement and third-party onboarding (SaaS selection, managed services, critical software)
• Change management (material changes that affect security posture)
• Risk management (formal acceptance of residual risk)

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

Use the sequence below as your minimum viable implementation for the sa-8(28): acceptable security requirement.

1) Define “acceptable security” thresholds by system category

Create an Acceptable Security Standard that answers, in operational terms:

• What security capabilities are mandatory (identity, encryption, logging, segmentation, secure update paths, etc.).
• Which designs are disallowed (examples: shared admin accounts, public management interfaces, unmanaged secrets).
• What assurance activities are required (threat modeling, secure design review, security testing depth).
• Who can approve exceptions and under what conditions.

Keep it measurable. “Must have centralized logging” is testable. “Should be secure” is not.

2) Embed the threshold into architecture and SDLC gates

Add explicit checkpoints where teams must show the design meets your acceptable threshold:

• Architecture review / design authority: required before build or purchase.
• Threat modeling: required for new systems and material changes; document abuse cases and mitigations.
• Security requirements review: verify requirements align to the acceptable standard and the system’s risk tier.
• Release readiness: confirm required controls and testing are complete.

This is where SA-8(28) becomes real: the gate blocks launch until the design is “acceptable” or an exception is approved.

3) Make third-party and procurement decisions part of “acceptable security”

For third parties (SaaS, PaaS, MSPs, embedded components), define procurement pass/fail criteria aligned to your acceptable threshold:

• Required security features (SSO/MFA support, audit logs, encryption, tenant isolation as applicable)
• Required documentation and attestations (what you accept varies by program)
• Required contractual terms (security incident notice, breach cooperation, audit rights where feasible)

If a third party can’t meet the threshold, your only compliant outcomes are: choose another provider, add compensating controls, or route an exception through formal risk acceptance.

4) Implement a formal risk acceptance and exception workflow

Auditors often focus on how you handle “not acceptable yet” designs. Establish:

• A standard exception record (control gap, rationale, compensating controls, residual risk, expiration date/trigger, owner)
• Approval routing (system owner + security + risk authority)
• Reassessment triggers (major change, incident, contract renewal, new data types)

Do not allow informal exceptions in tickets with no risk owner signature.

5) Verify acceptability with evidence-backed assurance activities

“Acceptable” must be supported by verification:

• Security test results tied to the design (configuration reviews, pen test summaries where applicable, cloud posture findings, SAST/DAST summaries)
• Hardening benchmarks and configuration baselines for deployed environments
• Evidence that monitoring/logging requirements were implemented and are active

6) Operationalize ownership and recurring evidence

Assign a control owner (often Security Architecture or Product Security) and define recurring evidence collection. If you use Daydream, set SA-8(28) up with:

• A named owner and reviewer
• A documented implementation procedure (what gates exist, what counts as pass/fail)
• A recurring evidence checklist tied to release cycles and major changes

This directly addresses the common failure mode: “we do design reviews” without consistent artifacts.

Required evidence and artifacts to retain

Keep artifacts that show definition, application, and verification:

Definition artifacts

• Acceptable Security Standard (by tier/system type)
• Secure architecture patterns and prohibited-pattern list
• Exception/risk acceptance policy and workflow

Application artifacts ¹

• Architecture diagrams and data flow diagrams
• Threat model and mitigation tracking
• Design review checklist and signed approval record
• Third-party security evaluation summary and decision record

Verification artifacts

• Security testing summaries mapped to key risks/design claims
• Configuration baseline evidence (selected settings, IaC policies, hardening guides)
• Logging/monitoring enablement evidence for required events

Exception artifacts

• Approved risk acceptance records with expiration/review triggers
• Compensating controls and follow-up remediation plan

Common exam/audit questions and hangups

Expect assessors to ask:

• “Show me your definition of acceptable security. Where is it documented and approved?”
• “Pick a recent system. Show the design review record and how you concluded security was acceptable.”
• “How do you prevent launches when designs are not acceptable?”
• “How do you handle exceptions, and who is the risk owner?”
• “How do third-party products get evaluated against your acceptability threshold?”

Common hangups:

• No explicit threshold: teams rely on general policies instead of system-specific criteria.
• No consistent artifacts: decisions happen verbally, in meetings, or in scattered tickets.
• Exceptions are permanent: risk acceptances never expire or get re-reviewed.
• Third-party security is separate: procurement bypasses the same acceptability standard used for internal builds.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating SA-8(28) as a policy-only control
   Fix: tie it to engineering gates (architecture review, threat modeling, release readiness) and require artifacts.

2. Mistake: Defining “acceptable” as “meets baseline controls”
   Fix: add design-specific acceptability criteria (for example, “admin plane must be private,” “audit logs must be immutable or centrally retained”).

3. Mistake: No documented tradeoffs
   Fix: require a decision record for high-risk choices (why this design, what alternatives were rejected, residual risk).

4. Mistake: Third parties escape design scrutiny
   Fix: require the same acceptability checklist for buy vs build, with documented compensating controls or exception approvals.

5. Mistake: Exceptions don’t have a risk owner
   Fix: make the business/system owner sign residual risk acceptance, with security providing analysis, not ownership.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source material, so you should not expect SA-8(28) to be cited by name in public actions based on this dataset. The practical risk is indirect: weak secure design governance increases the likelihood of control failures across identity, logging, segmentation, change control, and supply chain security, which are frequently examined in audits and often implicated in incident postmortems. (NIST SP 800-53 Rev. 5)

Practical execution plan (30/60/90-day)

Use this as an operator plan. Adjust for your SDLC and authorization model.

First 30 days (establish the minimum standard and ownership)

• Assign SA-8(28) control ownership (Security Architecture or Product Security) and name required approvers.
• Publish an Acceptable Security Standard (versioned) with clear pass/fail requirements and an exception path.
• Add an “acceptable security” section to architecture review templates and third-party intake forms.
• Define the evidence list you will collect for each new system and material change.

By 60 days (make it real in system delivery and procurement)

• Implement mandatory design review and threat modeling gates for in-scope systems.
• Stand up the exception workflow with required fields, approvals, and review triggers.
• Pilot the process on a small set of systems (one internal build, one third-party service).
• Start storing artifacts in a consistent repository structure (system record, decision log, exception register).

By 90 days (scale, measure, and prepare for assessment)

• Expand gates to cover all in-scope product lines and major change types.
• Add periodic review for open exceptions (staleness is what auditors find).
• Run an internal assessment: pick two systems and rehearse the audit narrative end-to-end using your retained artifacts.
• If you use Daydream, automate evidence requests and reminders so SA-8(28) stays current across releases and renewals.

Frequently Asked Questions

What is “acceptable security” supposed to mean in SA-8(28)?

It means you define an explicit threshold for security risk and required design features, then show each system design meets that threshold or has an approved exception. The evidence should demonstrate deliberate, reviewed design decisions, not informal agreement. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Does SA-8(28) apply only to custom-built systems?

No. It applies to systems you build, buy, or integrate, including third-party services that process your data or sit in your operational environment. Treat procurement and third-party onboarding as part of the design decision. (NIST SP 800-53 Rev. 5)

What evidence do auditors usually want for SA-8(28)?

They want your definition of acceptable security, proof you applied it (design review records, threat models, architecture diagrams), and proof you verified it (test summaries, configuration baseline evidence). They also look for documented exceptions with risk owner approval. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How do we handle cases where the business insists on shipping with known security gaps?

Route the gap through a formal risk acceptance process with a named risk owner, compensating controls, and a defined re-review trigger. If you cannot get a documented acceptance, treat it as a launch blocker under your acceptable security gate.

How do we operationalize this without slowing delivery to a crawl?

Standardize patterns and checklists by system tier so most designs pass through a lightweight review, and reserve deep review for high-risk systems and non-standard architectures. The goal is consistent decisions and artifacts, not paperwork volume.

Where does Daydream fit for SA-8(28)?

Daydream is useful for assigning a clear control owner, documenting the implementation procedure, and generating recurring evidence tasks so design-review and exception artifacts are collected consistently across teams and releases.

Footnotes

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