SA-12(15): Processes to Address Weaknesses or Deficiencies

SA-12(15) requires you to have defined, repeatable processes to find, track, and fix weaknesses or deficiencies tied to your supply chain and system components, and to prove those processes run in practice. Operationalize it by assigning a control owner, documenting intake-to-remediation workflows, and retaining recurring evidence that deficiencies are identified, prioritized, resolved, and verified. ¹

Key takeaways:

• You need a documented process that connects “weakness found” to “fix verified,” with clear ownership and timelines.
• Evidence matters as much as intent: tickets, supplier communications, approvals, and closure verification must be retained.
• Treat third-party and component deficiencies as first-class remediation work, not informal email follow-ups.

SA-12 sits in the System and Services Acquisition family, so SA-12(15): processes to address weaknesses or deficiencies should be read through a supply chain lens: products, components, integrators, SaaS, cloud, and any third party that affects your system. The control is easy to “say yes” to and still fail in an assessment, because assessors look for operational proof that weaknesses get from discovery to verified remediation without falling into a gap between Security, Procurement, Engineering, and the supplier.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SA-12(15) as a workflow control, not a policy control. You are building an intake-and-resolution mechanism that (1) captures deficiencies from multiple sources, (2) triages and assigns them, (3) drives remediation through a tracked plan, (4) validates closure, and (5) produces evidence on demand. Your goal is audit-ready repeatability: the same steps, the same artifacts, every time, across internal teams and third parties.

Where teams struggle: deficiencies discovered during vendor due diligence or technical testing often lack a formal “home” for remediation. SA-12(15) closes that gap with defined processes and records. ²

Regulatory text

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

Operator interpretation: You must define and operate processes that address identified weaknesses or deficiencies related to system and service acquisition and the supply chain. In practice, that means you can show: (a) how deficiencies are identified, (b) how they are recorded and prioritized, (c) who must act (internal owner and, when relevant, the third party), (d) how fixes are tracked to completion, and (e) how you verify the fix worked before closure. ²

Plain-English interpretation (what SA-12(15) is asking for)

SA-12(15): processes to address weaknesses or deficiencies requirement expects a closed-loop remediation program for acquisition and supplier-related issues. “Weaknesses or deficiencies” includes security gaps in supplier controls, insecure component configurations, missing contractual obligations, unsupported software components, incomplete SBOM-related follow-up, and unresolved findings discovered during onboarding or periodic reviews.

A passing implementation has three traits:

1. Repeatable workflow: the same steps apply whether the issue is found in a SOC 2 review, a penetration test, a vulnerability scan, a contract review, or an incident postmortem.
2. Accountability: each deficiency has a single accountable owner, even if multiple teams contribute.
3. Verifiable closure: closure requires evidence of remediation and validation, not “vendor said it’s fixed.”

Who it applies to (entity and operational context)

Entity types most commonly scoped:

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually or used as the baseline for security requirements. ¹

Operational contexts where SA-12(15) shows up in audits:

• Third-party onboarding and re-assessments (security questionnaires, SOC reports, SIG/CAIQ, ISO cert reviews).
• Software supply chain (components, libraries, container images, CI/CD tooling).
• Hardware/firmware acquisition, managed service providers, and cloud services.
• Mergers, divestitures, and inherited vendor portfolios where known issues exist but tracking is fragmented.

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

1) Assign ownership and define scope boundaries

• Name a control owner (often Third-Party Risk, Security Assurance, or GRC) accountable for the process working end-to-end.
• Define what counts as a “deficiency” for this control: supplier control gaps, product vulnerabilities affecting acquired components, contractual nonconformance, and any finding that requires action to reduce supply chain risk.
• Define what is out of scope (example: purely internal app bugs unrelated to acquired components), but be careful: auditors may still expect routing into your broader remediation program.

Daydream fit (practical): Map SA-12(15) to a single owner, a written procedure, and a recurring evidence set so it doesn’t become an “everybody owns it, nobody runs it” control.

2) Build a single intake path for deficiencies (multiple sources, one queue)

Create an intake mechanism that captures deficiencies from:

• Third-party assessments (questionnaire gaps, SOC report exceptions, pen test summaries)
• Internal testing (SAST/DAST results tied to acquired components, dependency scanning)
• Procurement and contract reviews (missing clauses, expired attestations)
• Incidents and post-incident reviews where a supplier or component contributed

Operational requirement: every intake item becomes a trackable record (ticket/case) with a unique ID, source, date identified, impacted system/service, and initial severity.

3) Triage and prioritize with defined decision criteria

Write triage criteria that is simple enough to run consistently:

• Impact: what data/process/system is at risk
• Exploitability/likelihood: is this actively exploitable or theoretical
• Supplier criticality: is the third party high-impact to mission or operations
• Compensating controls: can you reduce risk while remediation is pending

Output artifacts: severity rating, rationale, and decision on the remediation path (fix, accept, transfer, or stop use).

4) Create and track a remediation plan with the supplier and internal teams

For each deficiency, require:

• Remediation owner: internal accountable party
• Action plan: what will be done, by whom (supplier vs your team), and dependencies
• Target dates: internal milestones and supplier delivery dates
• Communication record: emails, portal messages, meeting notes, or formal letters

If a supplier is responsible, route through your vendor management function so commitments are documented and enforceable through the contract where possible.

5) Verify remediation and close with evidence, not assertions

Closure should require one or more of:

• Updated supplier attestation or report excerpt that addresses the gap
• Evidence of a control implementation (configuration screenshots, change record, test result)
• Re-test results (scan shows vulnerability resolved; pen test retest letter)
• Contractual amendment executed (for contract deficiencies)

Define who can approve closure and what “proof” is acceptable by deficiency category.

6) Run the process on a cadence and report exceptions

Auditors expect this to be operational, so schedule:

• A standing review of open deficiencies (aging, overdue items, blocked items)
• Escalation rules (when to involve Legal, Procurement, or senior risk committee)
• Metrics that are evidence-backed (counts by status and age bands from the system of record; avoid vanity metrics you cannot substantiate)

Required evidence and artifacts to retain

Keep evidence in a way that can be pulled per system, per supplier, and per time period.

Minimum artifact set (typical assessor expectations):

• SA-12(15) procedure (intake → triage → remediation → verification → closure) ²
• Control ownership and RACI for stakeholders (GRC, Security, Procurement, Legal, Engineering)
• Deficiency register (ticket export) with required fields and status history
• Samples of closed deficiencies with:
  • discovery source record (assessment report excerpt, scan output, contract review note)
  • triage rationale and approval
  • remediation plan and communications with third party
  • verification evidence and closure approval
• Exception/risk acceptance records when you do not remediate
• Periodic reporting or meeting minutes showing governance oversight

Common exam/audit questions and hangups

Questions you should be ready to answer with artifacts:

• “Show me your process for addressing supplier-related deficiencies end-to-end.” ²
• “How do you ensure deficiencies found during onboarding are tracked to closure after go-live?”
• “Who can accept risk, and where is that decision recorded?”
• “Provide examples where a third party missed a commitment. How did you escalate?”
• “How do you validate the fix, and what prevents premature closure?”

Hangups that trigger findings:

• Evidence scattered across email, spreadsheets, and procurement tools without a single system of record.
• “Closed” items without verification evidence.
• Remediation owned by the supplier with no internal accountable owner.
• No ability to produce a population of deficiencies for a defined audit period.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating SA-12(15) as a policy statement	Auditors test operation, not intent	Implement a ticketed workflow with required fields and approvals
Tracking third-party deficiencies in a separate spreadsheet	Data becomes stale and unverifiable	Use one queue/system and tag records as “third party” or “supplier-caused”
Closing based on supplier assertion	No validation	Require retest evidence or artifact-based proof before closure
No defined risk acceptance path	Teams “park” issues indefinitely	Create a documented exception process with approvers and expiry review
Procurement owns contracts, Security owns findings, nobody owns closure	Work stalls	Assign a single accountable owner for closure and reporting

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Risk-wise, weak SA-12(15) execution creates predictable failure modes: known supplier deficiencies remain open, compensating controls are informal, and risk acceptance decisions cannot be reconstructed. In federal and federal-adjacent assessments, that typically converts into audit findings, delayed authorizations, or contractual noncompliance exposure, depending on how NIST SP 800-53 is incorporated into your obligations. ²

A practical 30/60/90-day execution plan

Day 0–30: Stand up the minimum viable process

• Assign the control owner and define deficiency scope categories.
• Publish a one-page procedure and a RACI.
• Choose the system of record (GRC tool, ticketing platform, or third-party risk platform) and define required fields.
• Run a short backlog sweep: find open supplier deficiencies across email, spreadsheets, and assessments, and import them into the queue.

Day 31–60: Make it auditable

• Define triage criteria and closure verification standards by deficiency type.
• Implement approval steps for risk acceptance and closure.
• Build an evidence package template for “sample testing” (what you will hand auditors for any closed ticket).
• Pilot with a small set of critical third parties and one internal product team.

Day 61–90: Operationalize and govern

• Establish a recurring review meeting for open deficiencies and overdue actions.
• Add escalation paths (Procurement, Legal, senior risk committee).
• Create reporting that can be generated on demand: open vs closed, aging, and exceptions.
• Validate readiness by running an internal “mock audit” sample: pick closed items and confirm the full evidence chain exists.

Frequently Asked Questions

What counts as a “weakness or deficiency” under SA-12(15)?

Treat it as any supplier- or acquisition-related gap that requires action to reduce risk: missing contractual security obligations, unresolved assessment findings, vulnerable components, or incomplete supplier attestations. Define categories in your procedure so teams classify items consistently. ²

Do I need a separate process for third-party deficiencies versus internal vulnerabilities?

You can use one remediation process as long as it clearly covers supply chain and third-party items and you can report them separately. Assessors mainly care that deficiencies are tracked to verified closure with clear ownership. ²

What evidence is most persuasive in an audit?

A closed ticket that includes the original finding, documented triage, a remediation plan, supplier communications, and verification proof before closure. A policy without sample records rarely passes testing. ²

How do we handle a supplier that refuses to remediate?

Record the refusal, escalate through vendor management and Legal, and document a formal risk acceptance or compensating controls decision with an expiry review. If the risk is unacceptable, document the decision to restrict use or transition off the supplier.

Can we accept risk and still be compliant with SA-12(15)?

Yes, if the acceptance is an explicit, approved outcome of your defined process and you retain evidence of the decision, rationale, and any required compensating controls. The failure mode is informal “acceptance by silence.”

How does Daydream help with SA-12(15) execution?

Daydream is a natural system-of-record layer for mapping SA-12(15) to an owner, a documented procedure, and recurring evidence artifacts, then keeping remediation records and audit samples consistent across assessors and time periods.

Footnotes

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

2. NIST SP 800-53 Rev. 5