SA-8(28): Acceptable Security

SA-8(28) requires you to bake the “acceptable security” design principle into the systems and components you build or acquire, meaning you define what “good enough security” is for each use case and prove the design meets that bar before release. Operationalize it with explicit security acceptance criteria, design reviews, and documented risk decisions tied to system requirements. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Define “acceptable security” as measurable acceptance criteria tied to mission, data sensitivity, and threat model, not a vague policy statement. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Make it a gating control in architecture/design and release workflows, with a documented exception path and risk acceptance. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Keep an evidence bundle that links requirements → design decisions → review/approval → resulting artifacts for each system/component. (NIST SP 800-53 Rev. 5 OSCAL JSON)

“Acceptable security” is a design principle: security has to be sufficient for the system’s purpose, risk exposure, and operating environment. For a CCO or GRC lead, the trap is treating SA-8(28) as a one-time policy statement. Auditors and customers will ask a simpler question: “Show me where you defined what security is acceptable for this system, who approved it, and how you verified it before go-live.”

SA-8(28) sits in the System and Services Acquisition (SA) family, so it applies to how you design, build, buy, and integrate technology. That includes internally developed applications, cloud deployments, COTS products, and third-party delivered components. The fastest path to operationalization is to translate “acceptable security” into a repeatable set of security acceptance criteria (by system type) and enforce those criteria at architecture review and release gates. The second requirement is evidence: you need traceability across requirements, design artifacts, and approvals for each system or major component change. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Regulatory text

Requirement (SA-8(28)): “Implement the security design principle of acceptable security in [systems or system components].” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What this means for operators

You must:

1. Define what “acceptable security” means for each system or component in scope, in terms that engineering can implement and testing can verify.
2. Embed those expectations into the design lifecycle (architecture, threat modeling, security requirements, and design review).
3. Enforce decision discipline when the system does not meet the bar (remediate, formally accept risk, or block release).
4. Prove it happened with durable artifacts tied to each system or component. (NIST SP 800-53 Rev. 5 OSCAL JSON)

NIST intentionally leaves “[systems or system components]” variable. Your job is to fill in scope based on your environment, authorizations, and contracts. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Plain-English interpretation (requirement-level)

Acceptable security is “security that is sufficient for the intended use and risk,” not “maximum security.” In practice, this means you define the minimum controls and design properties a system must have (and what risks it may still carry) before it can handle a given data type or support a given business process.

A workable interpretation for audits:

• For each system/component: security acceptance criteria exist, are approved, and are testable.
• Design and implementation demonstrably meet those criteria prior to production use.
• Exceptions follow a documented risk acceptance process with defined owners and expiration or review triggers. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who it applies to

Entity scope

SA-8(28) is commonly expected in:

• Federal information systems
• Contractor systems handling federal data (including environments supporting federal programs or contracts) (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational scope (what you should include)

Treat these as in-scope unless you explicitly document a carve-out:

• New internally developed applications and major features
• Infrastructure components (identity, networking, logging pipelines, CI/CD runners)
• Cloud services and configurations (IaaS/PaaS/SaaS)
• COTS software and appliances
• Third-party components embedded into your product (libraries, SDKs, managed services) (NIST SP 800-53 Rev. 5 OSCAL JSON)

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

Step 1: Create a “SA-8(28) control card” (one page)

Write a runbook-style control definition that an auditor and an engineer can both follow:

• Objective: Implement acceptable security by defining and enforcing security acceptance criteria in design and release.
• Owner: Name a role (e.g., Head of Product Security, Architecture Review Board chair).
• In-scope systems/components: Define inclusion rules (e.g., “any system processing federal data”).
• Trigger events: New system, major architectural change, new third-party component, material change in data classification.
• Execution steps: See Steps 2–6 below.
• Exceptions: Risk acceptance authority, required documentation, and re-approval triggers. (NIST SP 800-53 Rev. 5 OSCAL JSON)

This is the fastest way to eliminate the common audit failure: nobody can explain “how SA-8(28) runs.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 2: Define “acceptable security” as security acceptance criteria

Create a standard set of acceptance criteria that you can tailor by system category. Good criteria are:

• Measurable (pass/fail)
• Mapped to requirements (security requirements or control objectives)
• Testable (via review, inspection, or technical validation)
• Tied to risk (data sensitivity, exposure, threat model)

A practical structure:

• Baseline criteria (apply to all systems): identity, logging, vulnerability management, secure configuration, encryption expectations, secure SDLC checks.
• Data-driven criteria (based on data type/classification): stronger encryption, access controls, monitoring.
• Exposure-driven criteria (internet-facing vs internal): WAF, DDoS considerations, rate limiting, more stringent hardening.
• Third-party criteria (when using external components): SBOM expectations, patching SLAs, security review of the supplier, contractual requirements. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 3: Attach criteria to the design workflow (make it a gate)

Embed the criteria into existing engineering ceremonies so it is not “extra compliance work”:

• Architecture review / design review checklist includes the acceptance criteria relevant to that system.
• Threat modeling (or equivalent risk analysis) is required for high-risk changes and feeds the criteria.
• Security requirements are recorded in the same system as product requirements (Jira/Azure DevOps/etc.) so they can be traced.

A common implementation pattern:

• “No architecture approval without completed acceptable security checklist + threat model summary for scoped systems.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 4: Define an exception and risk acceptance path that engineering will use

You will face tradeoffs (time, performance, third-party constraints). SA-8(28) does not prohibit risk; it requires disciplined decisions. Minimum exception workflow:

• Document the unmet acceptance criterion
• Document compensating controls (if any)
• Assign a risk owner (business owner, not only security)
• Obtain approval from designated authority
• Define a review trigger (e.g., next major release, new vulnerability, contract change)
• Record decision in a central register linked to the system/component. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 5: Verify before release (don’t rely on intent)

Tie “acceptable security” to release readiness:

• Security review sign-off references the acceptance criteria list
• Evidence of verification exists (design review minutes, scan results, configuration checks, test results)
• Open items are tracked with owners and due dates, or formally accepted as risk. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 6: Run control health checks (prove sustained operation)

Set a recurring cadence to confirm the mechanism still works:

• Sample recent releases/changes and confirm the acceptance criteria and approvals exist
• Confirm exceptions have not expired and are still justified
• Track remediation items to validated closure with due dates. (NIST SP 800-53 Rev. 5 OSCAL JSON)

If you manage controls in Daydream, this maps cleanly to a control card, an evidence checklist, and recurring operating tests with remediation tracking.

Required evidence and artifacts to retain (minimum evidence bundle)

Keep artifacts per system/component and per major change. Auditors want traceability.

Core artifacts (store centrally; linkable)

• SA-8(28) control card (owner, scope, triggers, steps, exceptions)
• System/component security acceptance criteria (baseline + tailored criteria)
• Design review record showing criteria were evaluated and approved (minutes, checklist, ticket workflow approvals)
• Threat model or risk analysis summary (where required by your triggers)
• Verification evidence (security testing outputs, scan summaries, configuration evidence, security review sign-off)
• Exception/risk acceptance records tied to specific unmet criteria, with approvals and review triggers
• Control health check results and remediation tracking to closure. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Common exam/audit questions and hangups

Expect these and pre-answer them in your artifacts:

1. “Define acceptable security for this system.” Provide acceptance criteria and tailoring rationale. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. “Show me it was enforced before production.” Produce design review approvals and release gate evidence.
3. “Who can accept exceptions?” Point to the control card and risk acceptance workflow.
4. “How do you treat third-party components?” Show supplier/component intake requirements and how exceptions are documented.
5. “How do you know it’s operating consistently?” Show control health check sampling and remediation closure evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequent implementation mistakes (and how to avoid them)

Mistake 1: “Acceptable security” equals “we follow best practices”

Fix: Write explicit acceptance criteria that are testable. If it can’t be tested, it won’t survive an audit.

Mistake 2: Criteria exist, but nobody uses them

Fix: Put the checklist inside the design approval workflow and require sign-off for scoped systems/components. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Mistake 3: Exceptions happen in Slack

Fix: Use a formal risk acceptance record with owner, rationale, and review triggers linked to the system.

Mistake 4: Evidence is scattered

Fix: Define an evidence bundle with a single retention location and naming convention per system and release.

Mistake 5: One-time rollout, no ongoing validation

Fix: Schedule recurring control health checks and track remediation to closure with documented validation. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific enhancement, so you should not expect a “SA-8(28) fine.” The risk is indirect but real: if you cannot demonstrate disciplined security design decisions, you will struggle with federal ATO expectations, customer due diligence, and audit findings tied to SDLC governance and system security engineering. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Practical 30/60/90-day execution plan

Use phased execution to get audit-ready quickly without stalling engineering.

First 30 days: Define and place the gate

• Publish the SA-8(28) control card with owner, scope, triggers, and exception authority. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Draft baseline security acceptance criteria and a tailoring guide by system category.
• Add a design review checklist section for “acceptable security” and require it for in-scope changes.
• Define the evidence bundle and central retention location (GRC tool, document repository, or ticketing system attachments).

Days 31–60: Pilot on real systems and fix friction

• Pilot on a small set of active projects (new system or major change).
• Tune criteria that are too vague or too hard to test.
• Stand up the exception/risk acceptance workflow with required fields and approval routing.
• Train architects, product owners, and security reviewers on “how to pass the gate” with minimal back-and-forth.

Days 61–90: Prove operation and scale

• Run a control health check sample across recent changes and document results.
• Close gaps: missing approvals, missing evidence, weak tailoring rationale.
• Expand scope to additional system categories and third-party component intake paths.
• Report metrics qualitatively to leadership (e.g., common reasons for exceptions, recurring design gaps) without inventing quantified claims. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequently Asked Questions

What does “acceptable security” mean in practice?

It means you define a minimum set of security requirements and design properties that are sufficient for the system’s purpose and risk, then you verify and approve them before release. The definition has to be testable and tied to the specific system or component. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Do we need to apply SA-8(28) to every minor code change?

Apply it based on triggers you define, such as new systems, major architectural changes, new third-party components, or changes in data sensitivity. Document those triggers in the control card so scope decisions are consistent. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How is SA-8(28) different from “secure by design” policy language?

SA-8(28) expects evidence that the design principle is implemented in systems or components, not just stated. The practical difference is a gate: defined acceptance criteria, design review, and recorded decisions. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What evidence is most persuasive to auditors?

Traceability: acceptance criteria linked to a specific system, a design review record that references those criteria, and verification evidence or documented exceptions with approvals. Keep it in a consistent evidence bundle per system/change. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How do we handle third-party components that can’t meet our criteria?

Treat it as an exception: document the unmet criteria, compensating controls, and obtain formal risk acceptance from the designated authority. Also record supplier follow-up actions like patch commitments or roadmap dependencies. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Can Daydream help operationalize SA-8(28)?

Yes, if you set up SA-8(28) as a control with a control card, a required evidence checklist, and recurring operating tests. The goal is consistent execution and defensible evidence across systems and releases. (NIST SP 800-53 Rev. 5 OSCAL JSON)