SA-17(3): Formal Correspondence

SA-17(3) sits in the NIST SP 800-53 System and Services Acquisition (SA) family and focuses on how you control and evidence communications with the developer of a system, system component, or system service. The practical compliance problem it addresses is simple: teams make security-significant decisions in informal channels (chat, hallway conversations, ad hoc calls), and later cannot prove what was requested, what was agreed, and what was delivered.

For a CCO, GRC lead, or Compliance Officer, the fastest path to “passable” implementation is to treat SA-17(3) as a procurement and delivery governance requirement: you (1) define the topics that require formal correspondence, (2) require the developer to communicate those topics through controlled channels, and (3) retain the record in a way an assessor can sample and trace to outcomes. You are not trying to bureaucratize every interaction. You are drawing a bright line around security-relevant communications so you can demonstrate accountability, traceability, and non-repudiation during assessments.

Primary sources for this requirement are NIST SP 800-53 Rev. 5 and the OSCAL catalog entry for SA-17(3) ¹.

Regulatory text

Excerpt (control enhancement): “Require the developer of the system, system component, or system service to:” ²

Operator interpretation of the excerpt: The text provided is a stub that signals a requirement you must impose on developers. Practically, you must (a) define a formal correspondence mechanism and (b) require the developer to use it for specified communications. Your implementation is judged less by the elegance of your policy and more by whether you can produce real correspondence artifacts that show the mechanism is in use and tied to development and delivery decisions ¹.

Plain-English interpretation (what SA-17(3) is asking for)

You need a controlled, written way to communicate security-meaningful requests, decisions, approvals, and exceptions with your developer, and you need to keep those records. “Formal correspondence” means the communication is:

• Identified (who sent it, who received it, when)
• Controlled (approved channel, access control, retention)
• Traceable (links to requirements, tickets, risk acceptances, change requests)
• Retrievable (you can produce it for an assessor sample)

In practice, this looks like contractually mandated use of a ticketing system, documented meeting minutes with approvals, signed letters/emails from authorized roles, and a correspondence register that your GRC team can sample on demand.

Who it applies to (entity and operational context)

SA-17(3) applies where you acquire or build systems through a developer relationship, including:

• Internal development teams acting as the “developer” for a federal information system.
• External third parties building or customizing a system, component, or service for you (including cloud service configuration, managed services, and embedded/OT components).
• Contractors handling federal data or operating federal information systems, where NIST SP 800-53 is your control baseline ³.

Operationally, you feel this requirement most during:

• System development and major enhancements
• Security architecture decisions and exceptions
• Vulnerability remediation and patch commitments
• ATO support, continuous monitoring, and audit response
• Changes to security requirements, SLAs, or shared responsibility boundaries

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

Step 1: Name the control owner and define “formal correspondence”

Assign a single accountable owner (often: Security GRC for the program, supported by Procurement and the System Owner). Document:

• Approved formal channels (e.g., contract notice letters, dedicated email distro with archiving, ticketing system queues, GRC tool workflow, signed meeting minutes repository)
• Authorized senders/approvers (e.g., ISSO, System Owner, Contracting Officer/Procurement, Security Architect)
• Required metadata (system name, component, requirement reference, risk ID, change/ticket ID)

Deliverable: SA-17(3) control procedure that states what counts as formal correspondence and where it is stored.

Step 2: Define triggers (what must be “formal”)

Write a short trigger matrix. Keep it operational. Example triggers:

• Security requirement interpretation disputes or deviations
• Risk acceptance requests and approvals
• Security test results, remediation plans, and closure statements
• Changes affecting security controls or boundary (including subcontractor changes)
• Vulnerability disclosures and patch timelines
• Secure configuration baselines and exceptions

Deliverable: Formal Correspondence Trigger Matrix mapped to your SDLC and change processes.

Step 3: Bake it into contracts and SOWs

Your strongest compliance posture comes from making it a developer obligation. Add language to:

• Master services agreement / contract clauses
• SOW / task order deliverables
• Development playbook / acceptance criteria

Minimum expectations to include:

• The developer must use designated channels for triggered topics
• The developer must respond within your defined governance workflow (not in ad hoc chat)
• The developer must provide written closure for key items (e.g., “remediation completed” with evidence link)

Deliverable: Contract/SOW clause library for SA-17(3) that Procurement can reuse.

Step 4: Implement workflow routing and retention

Make the process easy to follow:

• Create a dedicated queue/project in your ticketing system for “Developer Formal Correspondence”
• Configure email journaling or archiving for the formal distro(s)
• Store signed minutes/decision memos in a controlled repository with retention rules
• Define how items are linked to risks, POA&Ms, change requests, and security requirements

Deliverable: Correspondence register (even a spreadsheet is acceptable if controlled) with pointers to the underlying artifacts.

Step 5: Operate it through sampling and review

Run periodic checks:

• Sample correspondence items for each developer and confirm required metadata and approvals exist
• Verify traceability (e.g., a security exception request links to an approved risk acceptance)
• Confirm retention and access controls (no local-only inboxes as the system of record)

Deliverable: Periodic control check record (sampling worksheet + findings + remediation tickets).

Step 6: Make it assessor-ready

Prepare an “evidence packet” per system:

• Procedure + trigger matrix
• Contract clause excerpt
• 3–5 real correspondence examples (redacted as needed)
• A correspondence log export showing dates, topics, and closure status

This is where teams often lose time. If you can produce this within a day, SA-17(3) is effectively operationalized.

Required evidence and artifacts to retain

Keep artifacts that prove both design and operation:

Design evidence

• SA-17(3) procedure (owner, channels, triggers, approvals, retention)
• Trigger matrix mapped to SDLC/change management
• Contract/SOW clauses requiring developer formal correspondence ²

Operational evidence

• Correspondence register (log) with unique IDs and links
• Tickets and attached decision records
• Signed meeting minutes or decision memos
• Email threads from archived formal distro accounts
• Risk acceptance approvals tied to developer requests
• Audit trail exports showing who approved and when

Retention evidence

• Records retention rule (what system holds the record, retention duration per your policy)
• Access control list for the repository/queue

Common exam/audit questions and hangups

Assessors and auditors tend to probe these points:

• “Show me the contract language that requires the developer to use formal correspondence.” ²
• “What topics require formal correspondence, and who decides?”
• “Give me a sample of formal correspondence for a security exception, a vulnerability, and a control-impacting change.”
• “Where is the system of record, and how do you prevent key decisions from living only in chat?”
• “How do you ensure subcontractors (developer’s third parties) follow the same rule?”

Hangup to anticipate: teams present a policy but cannot show real artifacts that match the policy’s definition of “formal.”

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in audits	Fix
“Formal correspondence” is defined as “email” without controls	Email without archiving, access control, or indexing becomes non-retrievable	Use a dedicated archived mailbox and/or ticketing system as system of record
Triggers are vague (“security issues”)	Staff can’t tell when to switch channels	Publish a trigger matrix with examples and required metadata
No procurement integration	Developers are not obligated to comply	Add clauses to contracts and SOW templates; make it a deliverable
Evidence is scattered	Sampling takes too long; records look incomplete	Maintain a correspondence register that points to artifacts
Approvals happen verbally	No non-repudiation	Require written approvals for exceptions, boundary changes, remediation closure

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-17(3), so you should treat this as an assessment-readiness and governance risk rather than a “headline enforcement” driver.

Risk implications are still real:

• ATO and audit risk: inability to prove decisions and developer commitments can lead to assessment findings or delays in authorization decisions ³.
• Operational risk: informal agreements can result in missed remediation, unclear shared responsibility, and disputes during incidents.
• Third-party risk: if the developer is a third party, weak correspondence controls make it harder to enforce security obligations and demonstrate due diligence.

Practical 30/60/90-day execution plan

First 30 days (establish the mechanism)

• Assign control owner and backups.
• Define “formal correspondence” channels and minimum metadata.
• Draft trigger matrix and socialize with Engineering, Security, and Procurement.
• Identify system(s) and developer relationships in scope; prioritize highest-risk systems first.

Next 60 days (contract and workflow integration)

• Add SA-17(3) clause language to contract/SOW templates for new work.
• For active developers, add the requirement via contract mod, governance memo, or delivery playbook appendix (choose the mechanism your procurement rules support).
• Stand up the correspondence register and ticketing/email archiving configuration.
• Train delivery managers and security reviewers on triggers and required artifacts.

Next 90 days (prove it operates)

• Run a sampling review and document results.
• Fix gaps: missing approvals, missing traceability, unclear triggers.
• Build the assessor “evidence packet” per system.
• Consider automation: Daydream can map SA-17(3) to a named owner, a documented procedure, and recurring evidence artifacts so you stop rebuilding the same evidence set each assessment cycle ².

Frequently Asked Questions

What counts as “formal correspondence” for SA-17(3)?

A controlled written record in an approved system of record (ticket, archived mailbox, signed memo/minutes) with identifiable parties, date/time, and traceability to a requirement, risk, or change. Define this explicitly in your SA-17(3) procedure ².

Do we have to make every developer communication formal?

No. Set triggers for security-significant topics and keep routine collaboration informal. Auditors care that your defined triggers reliably produce retained records.

Can Teams/Slack messages count as formal correspondence?

Only if you treat the tool as a controlled record system: access control, retention, exportability, and a way to index and retrieve threads for sampling. Many teams instead route triggered items into tickets and store chat links as supporting context.

How do we apply this to agile development without slowing delivery?

Put the formality into the workflow you already run: tickets for security decisions, structured change records, and short decision memos for exceptions. Keep the trigger set tight so only high-impact items require the extra steps.

What evidence is fastest to produce during an audit?

A correspondence register plus a small set of samples that map to your triggers (exception, vulnerability remediation, control-impacting change), each with an approval record and link to closure evidence.

We have multiple developers and subcontractors. Who is responsible?

You are responsible for imposing and verifying the requirement. Make your prime developer accountable for flowing down the correspondence obligations to its third parties, then sample for compliance during delivery governance.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5