SA-17(3) Developer Security and Privacy Architecture and Design | Formal Correspondence
Require the developer of the system, system component, or system service to: (a) Produce, as an integral part of the development process, a formal top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions, error messages, and effects; (b) Show via proof to the extent feasible with additional informal demonstration as necessary, that the formal top-level specification is consistent with the formal policy model; (c) Show via informal demonstration, that the formal top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware; (d) Show that the formal top-level specification is an accurate description of the implemented security-relevant hardware, software, and firmware; and (e) Describe the security-relevant hardware, software, and firmware mechanisms not addressed in the formal top-level specification but strictly internal to the security-relevant hardware, software, and firmware.
Source: NIST SP 800-53 Rev 5, SA-17(3). The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open NIST SP 800-53 Rev 5 in the compliance library.
Base controls and their enhancements. Which apply follows the baseline you are assessed against (for example FedRAMP Moderate or High, or the low, moderate and high baselines of SP 800-53B). Text in square brackets is a parameter your organisation sets.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
none for this control
periodic reviewEvidence produced at each review
none for this control
governing documentDocuments that govern the control
- System and services acquisition policy · Policy repository / GRC workspace
- Enterprise architecture policy · Policy repository / GRC workspace
- Formal policy model · Policy repository / GRC workspace
- Procedures addressing developer security architecture and design specifications for the system · Policy repository / GRC workspace
- Solicitation documentation · Document repository
- Acquisition documentation · Document repository
- Service level agreements · Vendor register / contract repository
- Acquisition contracts for the system, system component, or system service · Vendor register / contract repository
- Formal top-level specification documentation · Document repository
First move
Common gaps auditors find
- No formal top-level specification describes the interfaces to security-relevant components
- Correspondence between the formal specification and the formal policy model is not shown
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheetSA-17(2) Developer Security and Privacy Architecture and Design | Security-relevant Components · SA-17(4) Developer Security and Privacy Architecture and Design | Informal Correspondence