SA-15(2): Security and Privacy Tracking Tools

SA-15(2) requires you to ensure the system developer selects and uses security and privacy tracking tools during the development process, and you can prove it with repeatable evidence. Operationalize it by defining a required toolset (or selection criteria), embedding it into SDLC gates and contracts, and retaining tool outputs that show the tools were actually used. ¹

Key takeaways:

• You must obligate developers (internal or third party) to use tracking tools during development, not after release. ¹
• “Tracking tools” means tools that record, manage, and report security and privacy work items and findings across the SDLC.
• Audit readiness depends on tool configuration and exported records (tickets, scans, SBOM/defect logs, approvals), not policy statements.

The sa-15(2): security and privacy tracking tools requirement is an SDLC control with a procurement and governance edge: you are not only expected to have security and privacy work happen, you must require the developer to use tools that track that work during development. That distinction matters in exams because teams often “do security” through meetings and ad hoc spreadsheets, then struggle to show what happened, when it happened, and who approved remediation.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SA-15(2) as a small set of enforceable “gates” plus durable evidence. Define what qualifies as a tracking tool in your environment, set minimum expectations (what must be tracked, what metadata must exist, how long records are retained), then bind those expectations to engineering workflows and third-party contracts. The control is medium severity in many baselines, but it becomes high impact for systems handling federal data because it directly affects your ability to demonstrate secure development and privacy-by-design practices during assessments. ²

Regulatory text

Requirement (verbatim): “Require the developer of the system, system component, or system service to select and employ security and privacy tracking tools for use during the development process.” ¹

What the operator must do: You must (1) put a requirement on the developer (internal team or third party) to select tracking tools, (2) ensure those tools are used during development, and (3) be able to demonstrate that usage with records produced by the tools. A policy that says “we track issues” is not enough; auditors will look for system-of-record evidence that security and privacy work items were created, triaged, resolved, and approved as part of the SDLC. ¹

Plain-English interpretation (what “tracking tools” means in practice)

“Security and privacy tracking tools” are tools that record and manage security/privacy-relevant work across the SDLC and produce an audit trail. Common categories include:

• Work tracking: issue/ticket systems used to log vulnerabilities, privacy findings, threat model actions, and security exceptions (with owners, due dates, status, approvals).
• Code and change tracking: version control and CI/CD logs showing when security checks ran and which commit/build they apply to.
• Security testing and scanning tools: SAST/DAST/SCA and container/IaC scanners that generate findings tied to builds or releases.
• Privacy engineering tracking: tools or workflows that track privacy requirements, data flow mapping tasks, DPIA/PIA actions, and data retention/deletion stories.

The key is not the brand. The key is: can you show that security and privacy requirements and findings were tracked from identification through closure during development?

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data where NIST SP 800-53 Rev. 5 is adopted as the control baseline. ²

Operational scope (where SA-15(2) shows up)

• Custom software development (apps, APIs, microservices).
• System components (libraries, containers, infrastructure-as-code modules).
• System services (managed services you build/operate, and in some cases third-party-developed services integrated into your environment).
• Third-party development where you outsource build work, buy a configurable platform, or rely on a systems integrator. SA-15(2) is a contract and delivery requirement as much as a technical control. ¹

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

Use this as requirement-level implementation guidance you can hand to engineering, procurement, and security.

1) Assign control ownership and define the “developer”

• Name a control owner in engineering/security (e.g., Head of AppSec or SDLC Governance) and a GRC owner for evidence collection.
• Define “developer” for your environment: internal product teams, DevOps/platform teams, and any third party building code or components for you. ¹

2) Define minimum tracking outcomes (tool-agnostic)

Create a one-page standard that states what must be tracked during development:

• Security and privacy requirements/tasks for each release or sprint
• Findings from security testing (manual or automated)
• Remediation actions with owners and due dates
• Risk acceptances/exceptions with approvals
• Release readiness approvals (security/privacy sign-off when required)

This prevents debates like “our scanner emailed results, that counts.” Email is not a tracking tool.

3) Specify approved tools or selection criteria

Pick one of two models:

• Standard toolchain model: You mandate the specific systems of record (e.g., one ticket system + one CI system + approved scanners).
• Criteria model (best for third parties): You require that the developer’s tools support required fields, exportability, retention, and access for audits, plus produce artifacts at delivery.

For third parties, the criteria model is often more realistic, but require evidence deliverables in the SOW.

4) Embed tool use into SDLC gates (make it unavoidable)

Add explicit gates to your SDLC that reference tool outputs, for example:

• “No merge without SAST/SCA job run attached to pipeline run”
• “No release without vulnerabilities triaged in ticket system and exceptions approved”
• “No production deploy without privacy stories completed for data-handling changes”

Keep the gate language testable: it should point to records you can export.

5) Contract it for third parties (SOW language + deliverables)

In contracts and SOWs, require:

• The developer will select and employ security and privacy tracking tools during development. ¹
• You receive deliverables: export of security/privacy backlog, findings register, exception log, and release approvals tied to the delivered version.
• You have audit access to tool outputs (exports are usually enough; full tool access can be hard).

If you use Daydream for third-party due diligence, this is where it fits cleanly: map SA-15(2) to a contract clause library, assign an owner, and generate an evidence checklist that vendors must satisfy at each delivery milestone.

6) Configure evidence retention and access

Decide:

• Where the system of record lives (internal instance vs third party exports)
• How exports are stored (GRC repository, secure file store)
• Who can access them for audits
• How you prevent “missing history” (deleted tickets, overwritten scan results)

7) Run a pilot assessment and fix gaps

Pick one active system and test:

• Can you trace a finding from scan → ticket → remediation commit → closure → release?
• Can you trace a privacy requirement from change request → task → review → approval? If you cannot, you have an operational gap even if tools exist.

Required evidence and artifacts to retain

Auditors typically want proof of use, not a list of tools. Retain:

• Tool inventory/standard: approved tools or selection criteria; tool owners; scope of use
• SDLC procedure: where tracking tools are required (PR template, pipeline gates, release checklist)
• Configuration snapshots: pipeline job definitions, required checks, ticket workflow states, required fields
• Exports from tracking tools ¹:
  • Security findings register (SAST/DAST/SCA/container/IaC)
  • Ticket queue for security/privacy items with status and timestamps
  • Exception/risk acceptance log with approvals
  • Evidence of closure (links to commits/PRs, retest results)
• Third-party deliverables: vendor-provided exports and attestations tied to versioned deliverables

Daydream can help by mapping SA-15(2) to a control owner, a documented procedure, and a recurring evidence set so the same artifacts appear every cycle without re-inventing the process. ¹

Common exam/audit questions and hangups

Expect these questions, and prepare your evidence around them:

• “Show me which tracking tools are required for this system’s development.”
• “Prove the tools were used during development for the last release.” ¹
• “How do you ensure third-party developers follow the same tracking expectations?”
• “Where are security exceptions tracked, and who approves them?”
• “Can you trace one high-risk finding from discovery to remediation and validation?”
• “How do privacy requirements get tracked when a change adds new data collection or sharing?”

Hangups that cause findings:

• Tools exist, but teams can bypass them.
• Evidence is scattered across email, chat, and local spreadsheets.
• Third parties provide a PDF summary with no underlying logs.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: equating “tracking” with “scanning.”
   Fix: scanning tools generate findings; you still need tracking workflows to triage and close them.

2. Mistake: no required metadata.
   Fix: require fields like severity, component, owner, target date, release tag, and exception status so exports are audit-grade.

3. Mistake: relying on manual screenshots.
   Fix: require exportable reports or API exports tied to release identifiers.

4. Mistake: third-party development treated as out of scope.
   Fix: add SA-15(2) deliverables to SOWs and acceptance criteria. ¹

5. Mistake: privacy tracking omitted.
   Fix: define what a “privacy work item” is (data mapping tasks, DPIA actions, retention changes) and track it in the same system of record.

Enforcement context and risk implications

No public enforcement cases were provided in your source catalog for SA-15(2). Practically, the risk shows up as assessment failure risk and inability to substantiate secure development claims during ATO/FedRAMP-style reviews or customer audits aligned to NIST SP 800-53. ²

Practical 30/60/90-day execution plan

First 30 days (establish the requirement and the evidence pattern)

• Assign owners (GRC + engineering/AppSec).
• Publish tool standards or selection criteria for “tracking tools.”
• Update SDLC procedures and templates to require tool references (tickets, pipeline runs, approvals).
• Update third-party SOW language and delivery checklists for SA-15(2). ¹

By 60 days (make it real in one system)

• Implement gates in CI/CD for one representative system.
• Configure ticket workflows and required fields for security/privacy items.
• Run an internal mini-audit: select a release and build a traceability package (finding → ticket → fix → retest → approval).

By 90 days (scale and normalize)

• Expand the same pattern across in-scope systems.
• Operationalize recurring exports into your evidence repository.
• Add third-party intake checks: no delivery accepted without the required tracking exports.
• Automate evidence collection where feasible (API exports from tools into your GRC evidence store).

Frequently Asked Questions

Does SA-15(2) force us to buy a specific security tool?

No. It requires the developer to select and employ tracking tools during development, but it does not mandate specific products. Your job is to define acceptable tools or criteria and retain proof the tools were used. ¹

We already have Jira. Is that enough to satisfy the sa-15(2): security and privacy tracking tools requirement?

Jira can satisfy the “tracking” part if it is the system of record for security and privacy work items and you can export evidence showing end-to-end handling. You still need inputs from scanning/testing tools or documented manual findings captured in Jira.

How do we handle third-party developers who won’t give us tool access?

Require exportable deliverables in the contract: findings register, ticket export, exception log, and release approvals tied to the delivered version. SA-15(2) is satisfied by demonstrable use, and exports can be sufficient evidence if they are complete. ¹

What counts as “privacy tracking” during development?

Track privacy requirements and findings as work items with owners, due dates, and approvals, the same way you track security vulnerabilities. Examples include data flow mapping tasks, retention/deletion changes, and reviews for new data collection.

What’s the minimum evidence packet an auditor will accept?

A tool standard/criteria document, the SDLC procedure showing where tool use is required, and tool outputs for a release that demonstrate findings and privacy tasks were logged, triaged, remediated, and approved. The packet should allow traceability from issue to closure. ¹

How can Daydream help without becoming another tool engineers ignore?

Use Daydream to set the requirement once (owner, procedure, evidence checklist) and to manage third-party deliverables and recurring evidence collection. Keep engineering in their existing systems; pull standardized exports into Daydream for audit readiness.

Footnotes

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

2. NIST SP 800-53 Rev. 5