What SA-17 asks for before any code is written
If you run a high-baseline system or a service that must meet FedRAMP Rev5, the design has to exist on paper before the build starts, not be reconstructed for the assessor afterward. SA-17 asks the developer to produce a security and privacy architecture and design specification that is consistent with the enterprise architecture, accurately describes the functionality the system must deliver, and shows how each control is allocated to specific components. It also has to show how the security functions work together, so that an assessor can trace a requirement from the enterprise level down to the component that enforces it. In SP 800-53B, SA-17 is selected only in the high security control baseline, and the FedRAMP Rev5 baselines require it at Class D. Confirm the applicable baseline and FedRAMP class in your authorization package before you scope the work.
The risk SA-17 addresses is structural. When controls are not allocated to components during design, gaps tend to appear at the seams between services, such as where an identity check is assumed by one component and never enforced by the next, or where logging is expected but no component owns it. These gaps are expensive to find after code is in production, and retrofitting a design rarely produces a document that matches what was built. Practically, the design specification should name each component, its trust boundary, the controls it implements or inherits, and the data flows between them, and it should be reviewed against the enterprise architecture before development begins. Ask your team which artifact currently serves this purpose, and whether it is kept under version control.
For a self-hosted platform, an implementation partner can help prepare the design specification, the control allocation mapping and the review records, but the organization owns the architecture decisions and the resulting accountability. Keep the design documents in a versioned repository or wiki so that changes are dated and attributable, and link each design decision to the requirements it satisfies. Only the independent assessor reviewing your authorization can judge whether the design meets SA-17, so use the SP 800-53A examine procedures for this control as the checklist for what evidence to prepare, including enterprise architecture documentation, configuration documentation, and solicitation and acquisition documents.
Which systems and teams SA-17 reaches in practice
SA-17 applies to a specific system, developer and set of architecture documents, so the first job is deciding which of these the control reaches. The cards below cover the decisions that most change the effort, and each one names the related controls (PL-2, PL-8, PM-7, SA-3, SA-4, SA-8 and SC-7) where the design has to connect.
Impact categorization of the system
SA-17 is selected in the SP 800-53B high baseline only, so the first question is whether the system's categorization is high. A moderate or low system does not carry the control as a baseline requirement, although an organization can still choose to adopt it. Confirm the categorization in the security plan (PL-2) before scoping SA-17 work, because it determines whether the design specification and architecture are required deliverables or optional good practice. Ask the system owner to record the decision and its basis.
Internal team or external developer
The control asks the developer to produce the design. When an internal engineering team builds the system, the organization owns the design document directly. When a contractor or software vendor builds it, the acquisition contract must require the design specification and architecture as deliverables (SA-4), and the contract should name the format, review points and acceptance criteria. Check whether the contractor's architecture is written in a form the organization can review and keep.
Components and interfaces in the design
The architecture has to describe how each security function is allocated to a component, including the interfaces between components. Build a list of every component, service, data store and external interface in scope, then map the security functions to each one. Missing interfaces are a common gap, especially for APIs, message queues and third-party integrations. Connect this inventory to the boundary protection design (SC-7) and to the secure engineering principles the developer applied (SA-8).
Enterprise architecture documents that already exist
SA-17 requires the design to be consistent with the enterprise architecture, so the scope depends on which enterprise architecture documents exist and how current they are. Inventory the reference architecture, technology standards, data flow diagrams and security architecture (PM-7 and PL-8 both bear on how these are maintained). Where no enterprise architecture exists, the assessor will have nothing to compare the design against, so this gap should be closed or recorded before assessment.
Development lifecycle and sequence of design
The design specification must exist before development decisions are locked in, so the scope includes where the design sits in the development lifecycle. Confirm the lifecycle stages from SA-3, identify the design review gate, and record who approves changes after that gate. Teams that treat architecture as a document written after the code often produce a specification that does not match the system an assessor tests.
How an assessor tests SA-17 and what they ask for
This table walks through how an SP 800-53A assessment of SA-17 is run, the evidence an assessor requests for each test approach, and where findings usually arise. Read it as a preparation checklist, keeping in mind that the assessor, not the implementer, makes the final determination.
| Assessment element | What the assessor does | Evidence requested | Common findings |
|---|---|---|---|
| Enterprise architecture alignment | Examines enterprise architecture documentation and compares it with the system design specification to confirm they are consistent | Enterprise architecture documents, the system design specification, and a traceability view linking the two | Design specification written at a different level of detail than the enterprise architecture, or never reconciled with it |
| Control allocation to components | Examines whether the design states which security and privacy controls each component implements | Component inventory with a control allocation matrix and the owner of each allocation | Controls described only at system level, leaving individual components without a clear owner |
| Functionality description | Checks that the design accurately describes the required functions, including security functions | Functional requirements, design diagrams and data flow descriptions for security functions | Security functions omitted from the design or described in terms that do not match the built system |
| Interaction of security functions | Examines how the design shows security functions working together, including dependencies and failure paths | Sequence or interaction diagrams and documented dependencies between security services | Design shows individual controls but not how they interact or what happens when one fails |
| System configuration settings | Examines configuration settings and associated documentation to confirm the design is reflected in the deployed system | Configuration exports, infrastructure as code, and records of how settings map to design decisions | Configuration drifts from the approved design with no record of the deviation or its approval |
| Solicitation and acquisition documentation | Examines solicitation and acquisition documents to confirm the architecture and design requirements were passed to the developer | Solicitation text, contract clauses requiring the design specification, and developer deliverable records | Contract silent on design deliverables, so the developer has no obligation to produce them |
How to build an SA-17 design package step by step
This sequence turns SA-17 into a design package that an assessor can trace from the enterprise architecture down to individual components, with each step producing a reviewable artifact and a named approver.
Confirm the enterprise architecture baseline
The enterprise architecture is the reference the SA-17 design must be consistent with, so start by confirming which version is authoritative. The enterprise architecture owner, with the system owner, records the baseline in a dated document, lists the business and technical domains it covers, and notes known gaps. Done means the baseline is versioned, signed by the enterprise architect, and stored where the assessor can retrieve it during examination of enterprise architecture documentation.
Define the security architecture views
Build the views that show how the system is structured, where trust boundaries sit, how data flows between components, and which external services are involved. The security architect drafts these views from the baseline, and the system owner checks them against the actual system. Done means each view has a stated purpose, a named owner and a version, and every boundary shown has a matching entry in the system security and privacy plan.
Allocate each required control to a named component
For every control the system must satisfy, record which component implements it and which component verifies it. The security architect produces an allocation matrix with one row per control and one column per component, and each row names an accountable owner. Done means no required control is left without an allocated component, and the matrix has been reviewed by the control owners who will later provide evidence for it.
Document how security functions interact
Describe how the allocated functions depend on each other, such as how authentication, logging, input validation and boundary protection hand off requests and failures. The developer writes sequence descriptions for the main transactions and for error and administrative paths. Done means a reviewer can follow one request end to end through every security function, and the document lists the assumptions each function makes about its neighbors.
Link acquisition and solicitation requirements
Trace each allocated security function back to the requirement in the solicitation or contract that obliges the developer to deliver it, and trace any function that a third party supplies to the acceptance criteria. The acquisition lead maintains this traceability table with the design owner. Done means every contracted security requirement points to a design element, and every design element that a supplier provides points to a contract clause the organization can enforce.
Set review gates and store the design specification
Define the gates at which the design must be reviewed, typically before build starts, before testing begins and before any significant change is accepted, and assign approvers for each gate. The system owner and security architect sign the design specification at each gate, and the change record shows what changed and why. Done means each signed version is stored with its allocation matrix, sequence descriptions and traceability table, and the organization can show which version was in force at each assessment.
Which evidence passes an SA-17 assessment
An assessor testing SA-17 looks for a design specification and security architecture that agree with the enterprise architecture, and for proof that the design was reviewed and kept current. The six artifacts below connect the design to the components it protects, the acquisition terms that require it and the tests that check it.
Design specification
The design specification describes the required functionality of the system and the security and privacy functions that deliver it. The assessor checks that it is consistent with the enterprise architecture and that it names each function in enough detail to be tested. Keep it in version control next to the code it describes, and confirm that each release identifies which specification version it was built against. A specification that stops matching the build is the most common reason this evidence fails.
Security and privacy architecture document
The architecture document shows how the security and privacy functions work together across components, including trust boundaries, data flows and dependencies on external services. An assessor reads it to confirm the structure explains the design rather than repeating it. Review it when the enterprise architecture changes, and record who approved each revision and why the change was needed.
Control allocation mapping
The allocation mapping ties each selected control to the component or layer that implements it, and to the owner responsible for it. It is the artifact that proves the design allocates controls, which is the core of the SA-17 requirement. Check that every control in the system security plan appears at least once and that no component is left without a responsible owner. Regenerate or review the mapping whenever a component is added, removed or moved.
Approval history in version control
The version history shows each revision of the design, who changed it, when, and who approved the change. Assessors use it to judge whether the design was maintained over time or written once for the audit. A wiki or document system that keeps every change with its author and timestamp supports this directly. Confirm that approvals are recorded by a reviewer other than the author and that rollbacks are logged too.
Acquisition clauses requiring the design
When a developer is external, the contract or statement of work must require the design specification and architecture as deliverables, with acceptance criteria tied to them. The assessor checks the solicitation and acquisition documents for that requirement and compares them with what was delivered. Review these clauses at each renewal or new work order so that new development teams are bound to the same design obligations.
Test plan links to design elements
The test plan links each security function in the design to the tests that verify it, so the design can be shown to have been tested as specified. An assessor samples a few functions and follows the link to a test case and its result. Keep those links current when functions change, and make sure failed tests are traced back to the design element they challenge.
What meeting SA-17 costs in money and effort
This table breaks the cost of meeting SA-17 into its main components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No figures are given because the supplied facts do not provide any, so use the drivers column to shape the scope you request in a quote. The main takeaway is that the design artifacts and evidence trail are sized by the system's architecture and the number of components, not by the tools chosen.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Architecture and design engineering | Internal architects or an implementation partner preparing the design specification and security architecture | One-time for the initial design, recurring when the design changes | Number of components, interfaces and external dependencies; how well the design already matches the enterprise architecture |
| Control allocation to components | Internal security engineers, with partner support if the allocation is new | One-time, then recurring with each significant change | Count of security functions that must be traced to specific components; clear enterprise control inheritance lowers effort |
| Tooling and licenses | Vendor or project for commercial tools; no license fee for community editions | Licenses recur; open-source tools carry hosting and maintenance effort instead | Choice of self-hosted open-source tools such as GitLab Community Edition or XWiki removes license spend, but hosting and upkeep remain |
| Evidence upkeep | Internal document owners, often supported by the partner for templates and version control | Recurring for each release, change or assessment cycle | Frequency of design changes, how well documents are kept under version control, and whether evidence is collected automatically |
| External review of the design | Independent reviewer or consultant, if the organization chooses to buy one | Usually one-time per design, repeated after major changes | Architecture complexity, number of security functions and whether internal reviewers have the required independence |
| Assessor sampling and interviews | Independent assessor, paid by the organization under its assessment contract | Recurring with each assessment cycle | Number of components and design artifacts the assessor samples, and how quickly staff can produce the requested documents |
How self-hosted open-source tools support SA-17 evidence
SA-17 asks for design specifications and a security and privacy architecture that the organization can trace to its enterprise architecture and to the controls each component implements. The four tools below cover different parts of that trail: who can change design and code, whether code is checked against rules, where design documents are versioned, and who can read or edit them. Each tool produces part of the evidence, and none of them writes the architecture or substitutes for an assessor's review.
Protected branches in GitLab
GitLab Community Edition (MIT) lets maintainers restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. For SA-17, this gives assessors a record that design-bearing code and configuration changes pass through a controlled merge path. Check that the protected branch settings match the approval roles named in your architecture governance, and confirm that exports of those settings are retained as evidence. Confirm the fit with your own environment before relying on the setting.
Code scanning with Semgrep
Semgrep Community Edition (LGPL-2.1-only) scans code in languages including Go, Java, Python, TypeScript and Terraform, using community or custom rules, and can run in CI/CD to scan repositories continuously. For SA-17, scan results show whether the implemented code follows the security functions the design allocates to each component. Confirm that your languages appear on the supported list and that custom rules encode your design constraints. LGPL-2.1-only terms apply, so have counsel review how you distribute any modified version.
Versioned design documents in XWiki
XWiki (LGPL-2.1-or-later) keeps every page change under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. For SA-17, this creates a history for the design specification and the security and privacy architecture, which assessors can use to see when an allocation of controls to a component changed and who approved it. Confirm that the page history is retained for the period your records policy requires, and that exports are included in the assessment package.
Role-based documentation access in BookStack
BookStack (MIT) assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. For SA-17, this lets you separate who can read the architecture from who can edit the allocation of controls, so that design changes come from the people accountable for them. Document the role matrix as part of the design evidence, and confirm that overrides on sensitive pages are reviewed when staff change roles.
Who writes the design, who prepares evidence and who assesses it
Your organization owns SA-17. The control asks for a design specification and security and privacy architecture that match your enterprise architecture, so the people who set that architecture must approve the design, decide how controls are allocated to components and accept the residual risk. An outside partner can draft material, but it cannot make these decisions for you, and an assessor will look for evidence that your architecture owners reviewed and signed off the design.
- Architecture authority: Name the owner of the enterprise architecture and confirm that the system design traces back to it.
- Control allocation decisions: Decide which component implements each security and privacy function and record the reasoning.
- Risk acceptance: Document who accepts gaps between the design and the required functionality, and at what level.
- Review records: Keep dated approvals, meeting minutes and change history for each design version.
- Contract inputs: Supply the requirements that flow into solicitations and acquisition documents for any developer you use.
Before engaging anyone, confirm which of these decisions your staff can make without an outside party and which need formal sign-off.
An implementation partner usually does the preparation work: drafting the security architecture document, building the allocation matrix that maps controls to components, configuring the open-source tooling that produces evidence and assembling evidence packages for the assessor. This work runs under a written scope that names deliverables, owners and acceptance criteria. The partner prepares the material and shows how it was produced, but it does not approve the design, issue findings or certify that SA-17 is met.
- Architecture document drafts: Write the design specification from your enterprise architecture and the system's functional requirements.
- Allocation matrix: Map each security and privacy function to the components that provide it, with the related controls named in the catalog.
- Tooling setup: Configure self-hosted platforms such as a Git server with protected branches, a code scanner in CI/CD and a version-controlled wiki for design records.
- Evidence packages: Collect configuration exports, review records and change history into an organized set the assessor can examine.
- Handover: Train your staff to maintain the documents after the engagement ends.
Costs recur when the design changes, so ask the partner to quote the update work separately from the initial build.
The independent assessor tests whether SA-17 is met using the assessment procedure in SP 800-53A. For SA-17, that procedure uses examine and interview methods across six determination statements, with objects such as enterprise architecture documentation, configuration settings, solicitation documentation and acquisition documentation. The assessor then issues the findings. Under a federal or FedRAMP engagement, the authorizing or assessing body defines who qualifies, so confirm the assessor type required by your contract or authorization before you select one.
- Independence: The assessor must not have designed the architecture or built the evidence it reviews.
- Examine and interview: Expect questions to architects, developers and the people who accepted risk, not only document review.
- Findings: The assessor records satisfied and not satisfied determinations, which your team then remediates or documents in a plan of action and milestones.
- Scope limits: Ask what the assessor will not cover, such as design choices made outside the assessed system boundary.
- Report ownership: The assessment report belongs to the assessor and the sponsoring organization, not to the implementation partner.
Ask each candidate assessor how they handle a partner's prepared evidence and where they draw the line on advice they can accept.
Where SA-17 designs usually fall short
SA-17 asks for a design that is consistent with the enterprise architecture and allocates controls to specific components. In practice, the gaps tend to appear at the same few points: timing, ownership, drift, contracts and records. Each card below names one gap and the check that closes it.
Design written after the build
The most common failure is a security and privacy architecture document produced once the system is already running, so it describes what was built rather than what was required. An assessor reviewing the design will find that it cannot show how security functions were chosen before implementation. Check that the design specification is dated before the build baseline and that later changes trace back to a revised design.
Allocation that names no owner
A design may list the controls a system needs without saying which component implements each one, or who answers for it. SA-17 expects the allocation of controls to be accurate, so a control with no named component and no named owner fails on inspection. Require a table that maps each control to a component, an interface and an accountable role.
Drift from the enterprise architecture
Teams often adopt a new service or data flow that the enterprise architecture never recorded, and the security design stays silent about it. The control requirement is that the design be consistent with the enterprise architecture, so unrecorded components are a finding. Compare the system design against the current enterprise architecture at each release and log every difference as a decision.
Contracts that never require the design
When acquisition documents omit a requirement for a security and privacy architecture, a developer or integrator has no obligation to produce one. SA-17 assessment looks at solicitation and acquisition documentation, so the gap is visible at the contract stage. Confirm that statements of work require the design specification, its format and its update obligations before award.
No version history for the design
A design kept as a single file that is overwritten on each edit cannot show what changed, when, or who approved it. An assessor asking how the allocation of controls evolved will have no answer. Keep the design in a system that records each revision, supports comparison between versions and allows rollback, and tie each revision to a review record.
Questions buyers ask about SA-17 cost, effort and help
How much effort does SA-17 take to meet?
The effort depends mostly on how much architecture already exists in writing. SA-17 asks for a design specification and a security and privacy architecture that match the enterprise architecture, describe the required functionality and allocate controls to each component, and show how the security functions work together. If the enterprise architecture is documented and current, the work is largely mapping existing components to controls and recording the allocation. If it is not, the effort rises because someone must first document the components, data flows and trust boundaries. The SA-17 assessment procedure in SP 800-53A examines enterprise architecture documentation, configuration settings, solicitation documentation and acquisition documentation, so the effort also includes making those documents consistent with each other. Ask any provider to size the work from a written scope that lists the systems, components and documents in play.
How long does a security architecture design package take?
No supplied source gives a duration for producing an SA-17 design package, so the timeline has to come from your own scope. The main variables are the number of systems in the boundary, how many components each one has, whether the enterprise architecture is current, and how many reviews the design needs before it is accepted. A single system with a small set of components and an existing architecture review process can move quickly. A multi-system environment with several third-party components, shared services and no current architecture baseline takes longer, mainly because decisions and reviews take time. Ask for a schedule that separates discovery, drafting, review and acceptance, and confirm which of those steps depend on your staff's availability.
What does the internal team need to provide for SA-17?
The internal team owns the design decisions and the evidence, so it has to supply the knowledge the design depends on. In practice this means:
- Enterprise architects who can confirm the target architecture and say which components are approved.
- System owners and engineers who can describe functionality, interfaces, data flows and current configuration.
- Security and privacy staff who can state which controls apply to each component and who accepts the allocation.
- Procurement or contract owners who can supply solicitation and acquisition documents for third-party components.
These people are needed for review and sign-off even when an outside provider drafts the documents. Confirm their availability before work starts, because a design waiting on a single architect is one of the most common causes of delay.
Can we produce SA-17 evidence in-house without outside help?
Yes, an organization can prepare SA-17 evidence in-house, provided it has people with architecture, security and acquisition skills and the time to do the work. SA-17 is a design control, so the organization owns it and can produce the specification itself. The harder question is whether the team can review its own design objectively and keep the documents consistent over time. Outside help is usually considered for drafting, facilitating the allocation exercise, or checking the package against the SP 800-53A examine objects before an assessor sees it. Any outside provider prepares the documents and the evidence. Only an independent assessor or authorizing official issues the assessment conclusion, so the in-house team should still plan for that review.
What should we confirm before hiring outside help for SA-17?
Confirm the written scope before comparing quotes, because a fixed scope is what makes proposals comparable. Ask the provider to list the systems in scope, the architecture documents it will review, the components it will allocate controls to, and the deliverables it will hand over. Ask who on your side must approve each deliverable and how many review rounds are included. Confirm that the provider prepares systems and evidence but does not issue assessment conclusions, and that your independent assessor has agreed on the evidence format in advance. Ask how the work will be kept current after the first version, since architecture changes will otherwise make the design package out of date.
What drives the cost of an SA-17 engagement?
Cost is driven by the amount of work the scope contains and the number of people who must be paid to do it. The main drivers are the number of systems and components, the state of existing architecture documentation, the number of third-party components that need supplier documentation, and the number of review rounds. Costs are typically one-time for the initial design package and recurring for keeping it current as the architecture changes. No supplied source gives a cost for SA-17, and NIST itself does not estimate compliance costs, so the figure should come from a written quote tied to a defined scope. Ask each provider to separate the one-time drafting cost from any ongoing maintenance or retainer cost.
Which SA-17 baseline applies, and does it change the effort?
SA-17 is assigned to the high security baseline in SP 800-53B, so it applies only when your system has high impact. For a system in the low or moderate baseline, SA-17 is not selected by default, and the design effort described here does not apply unless your authorizing body or contract requires it. For a high baseline system, the effort is greater because the control's enhancements and assessment procedures apply in full, and the design must be detailed enough to support the assessor's examination. Confirm the impact level and any overlay or tailoring decisions with your authorizing official before you scope the work, because the baseline determines what the design package must contain.
How DeployOpen prepares SA-17 design evidence
DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, and prepares the design specification, architecture and evidence that SA-17 asks for. The organization owns its controls and its architecture decisions, and an independent assessor is the party that tests them and issues any report.
How we scope
- Engagements are fixed-scope, with the systems, components and design documents agreed in writing before work starts.
- The written scope names which components the design allocates controls to and which enterprise architecture documents it must match.
- Scope also confirms whether a high baseline system is in play, since SA-17 applies only there under SP 800-53B.
How we build
- We draft the design specification and security and privacy architecture against the enterprise architecture the client supplies.
- Each security function is mapped to the component that performs it, showing how the functions work together.
- Design reviews are recorded with the decisions, open questions and the people who approved each allocation.
How we hand over
- Deliverables include the design specification, control allocation tables and architecture diagrams in formats the client keeps under version control.
- Repositories such as GitLab protected branches can hold design artifacts so approval history and changes are traceable.
- Handover includes a walkthrough so the client's assessor can trace each design element to the evidence that supports it.
How we support
- Ongoing support, design updates and continuous testing are available as retainers after the initial handover.
- Updates are reviewed when the enterprise architecture or system components change, so the design stays consistent with them.
- Confirm with DeployOpen during scoping which assessor will review the evidence and what format that assessor expects.
