What SA-11 developer testing requires and why assessors check it
If an audit, contract or authorization requires SA-11 at the moderate, high or privacy baseline, or a FedRAMP Class C or D system, the question an assessor will ask is simple: does the developer test the system on a planned schedule after design, and can the organization show the results and the fixes that followed? SA-11 asks for exactly that. The developer, at every post-design stage of the life cycle, must plan and run ongoing security and privacy control assessments, test at a defined frequency, depth and coverage, keep evidence of the results, and fix flaws through a remediation process that can be verified. The risk the control addresses is code that reaches production without anyone having tested it against the security and privacy requirements, or with defects that were found and never closed.
The control is hard to meet for a reason that has little to do with the tools. Many teams do test. They run unit tests, scan builds and perform occasional penetration tests, but the activity is not planned in a developer assessment plan, the depth and coverage of each test are not defined, the results are scattered across pipelines and tickets, and findings are not linked to a remediation record. Assessors then examine the security and privacy architecture, the developer's assessment plans and the flaw and remediation tracking records, and a gap in any one of them is usually visible. Confirm early which baseline and which FedRAMP class applies, because SA-11(1) is required at Classes C and D under the FedRAMP rules, and confirm with the assessor how they expect the plan, results and remediation records to be packaged.
Start with three decisions. First, decide who the developer is for each component, whether internal teams or an external provider, because the obligation attaches to that party and the acquisition contract must say so. Second, write the developer security assessment plan with the test types, frequency, depth and coverage for each release path. Third, make sure every test result and every flaw has an identifier that links to a fix and a verification step. Open-source tooling such as GitLab protected branches, Semgrep in the pipeline and a vulnerability inventory can produce much of this evidence, but the plan and the remediation rules are decisions the organization must own and document.
Which systems, teams and suppliers fall under SA-11 developer testing
SA-11 is not applied uniformly. Which baseline a system sits in, who builds its components, and which enhancements the organization selects decide how much testing evidence must exist and who produces it. The cards below take these decisions one at a time, starting with the baselines that select the control and ending with the suppliers whose work counts toward it.
Moderate, high and privacy baselines
SP 800-53B assigns SA-11 to the moderate and high security baselines and to the privacy baseline, so a low-impact system with no privacy scope does not select it by default. Confirm the impact level in the system's security categorization before scoping testing. A system that processes PII can pull SA-11 in through the privacy baseline even when its security impact is low, so check both sides of the categorization.
No enhancements assigned to baselines
In Release 5.2.0, SA-11 has nine control enhancements, but none is assigned to an SP 800-53B baseline. The organization must therefore decide which enhancements to adopt and document that choice in the system security and privacy plan. An assessor will look for the rationale, not just a list of selected items. Treat the base control as the baseline requirement and each enhancement as a separate, justified scoping decision.
FedRAMP Rev5 Class C and D
FedRAMP's Rev5 baselines require SA-11, SA-11(1) and SA-11(2) at Classes C and D, which makes these enhancements mandatory for cloud providers in those classes, not optional. Providers must also include SA-11(1) in a FedRAMP independent assessment at least once a year. Cloud providers should confirm their authorization class early, because it changes both the enhancement list and the assessment cadence.
Organization-defined parameters per system
SA-11 carries three organization-defined parameters that set the testing frequency, depth and coverage, and the enhancements selected per system determine which of them apply. A low-change internal tool and a customer-facing payment service should not share the same values. Record each parameter value in the system security plan with the risk reasoning behind it, and expect an assessor to test whether the stated values are actually followed.
In-house development teams
Internal engineering teams are the simplest case because the organization directly controls the developer's plans, test records and remediation tracking. SA-11 still requires ongoing assessment plans, defined testing and evidence of results at every post-design stage, so internal teams must produce those records as routine output rather than assembling them before an audit. Check that code review, test runs and flaw tickets are linked to the same system identifier.
External developers and vendor-built components
When a contractor or vendor builds part of the system, the acquisition contract must require the developer to produce SA-11 evidence, including test plans, results and flaw remediation records. Without these contract terms, the organization may not be able to obtain the records an assessor asks for. Review the SA-4 requirements and the SA-9 supplier oversight terms together with SA-11, and confirm that the developer's tools and pipelines can export evidence in a usable form.
How an assessor tests SA-11 and what they ask to see
This table walks through the elements an assessor works through for SA-11, the method used for each, and the evidence to have ready. Read it as a checklist of what the developer must be able to show, and note the common findings where plans and actual testing diverge. The main takeaway is that the assessor compares the written testing plan against the records of what was run and fixed.
| Assessment element | Method | What the assessor checks | Evidence to have ready |
|---|---|---|---|
| Developer security and privacy assessment plan | Examine | The plan defines what is tested, how often, to what depth and coverage, and who is responsible. | Approved plan, scope by test type, schedule, and named owners. |
| Flaw and remediation tracking records | Examine | Each flaw is logged, triaged, fixed and verified through a traceable process. | Tracker export with timestamps, severity, fix reference and closure check. |
| Security and privacy architecture | Examine | Test coverage maps to the architecture, so high-risk components are not left untested. | Architecture documents linked to test cases or test suites. |
| Privacy impact assessment | Examine | Privacy risks identified in the assessment are reflected in testing of PII handling. | PIA findings mapped to privacy test cases and their results. |
| Developer interview | Interview | Who sets test depth and coverage, how failed tests are escalated, and how results reach the tracker. | Named roles, a walkthrough of the pipeline, and a sample of recent decisions. |
| Test activities (unit, integration, system, regression) | Test | Tests run as planned, results are recorded, and regression runs after changes. | CI pipeline logs, test reports, and coverage data for a sampled release. |
| Remediation verification | Test | A sample of fixed flaws is retested to confirm the fix works and did not break other functions. | Retest results linked to the original finding and the code change. |
| Common finding: plan does not match practice | Examine and test | The plan lists test types or frequencies that the records show were never run. | Reconcile the plan against test history before the assessment starts. |
| Common finding: gaps in flaw records | Examine | Flaws closed without evidence of a fix, or fixes with no link to a finding. | Require a fix reference and verification step before a flaw can be closed. |
How to implement SA-11 in an existing development process
This sequence turns SA-11 from a policy statement into a working developer testing program, with defined parameters, a written assessment plan, automated tests in the pipeline, tracked flaws and a set of enhancements matched to the system. Each step ends with a record an assessor can examine.
Set the testing frequency, depth and coverage
SA-11 leaves the testing frequency, depth and coverage to the organization through its organization-defined parameters, so the first decision is to write them down. The system owner, security lead and development manager agree the values, and the security architect records them in the system security and privacy plan. Done means each parameter has a stated value, a named owner and a link to the test suites that meet it. Ask the assessor which values they will test against before you finalize them, since vague wording such as 'regularly' is hard to verify.
Write the developer assessment plan
Write a developer security and privacy assessment plan for the system that names the tests, tools, environments, responsible roles and pass criteria for each stage of the life cycle. The development lead drafts it, and the security team reviews it against the design and architecture documents. Done means the plan is approved, versioned and stored with the other system documentation, because an assessor will examine it directly as a required artifact. Include how privacy tests are handled if the system processes PII.
Wire unit, integration, system and regression tests into the pipeline
Add the planned test levels to the continuous integration pipeline so that each change runs unit, integration and system tests, and so that regression suites run before a release. Engineers configure the pipeline, and the platform team keeps it under version control. Done means a failed security or functional test blocks the merge or the release, and the pipeline keeps run logs that show which tests ran against which commit. Confirm that your CI platform retains those logs long enough to meet your evidence retention rules.
Track flaws with a remediation path and closure criteria
Route every defect found by testing, code review or scanning into a flaw tracking system with a severity, an owner, a remediation path and written closure criteria. The security lead defines the severity categories and closure rules, and developers work the tickets. Done means each closed flaw links to the fix commit, the retest result and the approver who accepted closure, which gives the assessor a complete chain from finding to verified fix. Keep open and deferred items visible with documented risk decisions.
Protect the repository and record who can change the code
Configure branch protection so that only authorized roles can push or merge to protected branches, direct pushes are blocked, and force pushes stay disabled unless explicitly allowed. The repository administrator sets these rules and exports the settings as evidence. Done means the configuration is documented, reviewed on a set schedule, and matched against actual merge history, so the assessor can see that tests and approvals were not skipped. This step supports the flaw remediation evidence in the previous step.
Select the enhancements that match the system
Review the nine SA-11 enhancements against the system's impact level and mission. Enhancements for independent verification, static and dynamic analysis, threat modeling, and penetration testing are the usual candidates for systems in the moderate and high baselines, although SP 800-53B does not assign any SA-11 enhancement to a baseline. The security architect decides which apply, documents the rationale and assigns owners. Done means each selected enhancement has a named test, tool and output, and each rejected one has a recorded reason. Confirm the expectations of your authorizing official or contract before you decide.
Run the static and dynamic analysis tools
Configure static analysis in the pipeline and run dynamic testing against a staging build to cover the enhancements you selected. Semgrep Community Edition scans many common languages and can run in CI/CD with community or custom rules, while dynamic testing needs a separate tool and test environment that you select and confirm for your stack. The security engineer owns tuning, and developers triage findings into the flaw tracker. Done means scan results are archived per release, each finding has a disposition, and tool versions are recorded so results can be reproduced.
Hand the evidence package to the independent assessor
Assemble the plan, parameter record, pipeline run logs, flaw tracker export, branch protection settings, scan reports and enhancement decisions into one evidence package, then give it to the independent assessor. The compliance lead owns the package and the assessor performs the examination and interviews. Done means the assessor has what the SA-11 assessment procedures ask to examine, and any gaps are logged as findings in the plan of action and milestones rather than fixed informally. DeployOpen prepares systems and evidence but does not issue assessment results.
Which evidence passes SA-11 and how to keep it current between audits
The SA-11 examine objects point to a small set of artifacts: the assessment plan, test results, flaw tracking records, the architecture under test and, where the privacy baseline applies, the privacy impact assessment. Each one goes stale quickly if it is only assembled before an assessment, so the refresh pattern matters as much as the first version.
Developer security assessment plan
The plan states which security and privacy assessments the developer runs, at what frequency, depth and coverage, and which tools and test types apply to each release. An assessor will compare what the plan promises against what the pipeline actually did. Keep the plan under version control next to the code, and update it whenever a pipeline stage, scanner or test type changes. Check that the plan names an owner and a review date, not just a version number.
Test results tied to each release
Assessors look for results that clearly belong to a specific build, not a general statement that testing happens. Export pipeline logs for unit, integration, system and regression runs, and record the commit hash and release identifier with each run. Store the exports in a location with retention longer than your release cycle. A run that cannot be traced to a release is the most common gap in this evidence.
Static and dynamic analysis reports
Where the enhancements for static and dynamic analysis apply, the reports are the proof. Self-hosted scanners such as Semgrep Community Edition can run in CI/CD on the languages your team uses and keep a per-commit record of findings. Confirm which languages your chosen tools cover before you rely on them, and keep the rule set version with each report so results can be reproduced.
Flaw and remediation tracking records
The tracking system should show each flaw with its discovery date, severity, assigned owner, fix reference, verification test and closure date. Ticket history matters more than the final status, because assessors sample closed items and check the timeline. Retain the full history, including reopened items and risk acceptances, and link each fix to the test run that verified it. Review a sample monthly so gaps appear before an assessment does.
Architecture the tests validate
Testing evidence is only meaningful against the architecture it was designed for. Keep the security and privacy architecture document current with each significant design change, and record which components each test suite covers. When a service is added, the test coverage map should change in the same change request. Tie architecture versions to test plan versions so an assessor can confirm the tests exercised the system as documented.
Privacy impact assessment for privacy baseline
Where the privacy baseline applies, the examine objects include a privacy impact assessment. Refresh it when the purposes of processing, categories of personal data or data flows change, and link each change to the test cases that cover the new processing. Confirm with your privacy office how often it must be reviewed, since SP 800-53 leaves that cadence to the organization. Store signed versions with dates so the history is clear.
Which open-source tools produce SA-11 evidence and how
GitLab Community Edition supports protected branches, which control who can push or merge to a branch and whether force pushes are allowed. Used on a development project, this gives the assessor a traceable record that changes to the system's code moved through a controlled path before reaching the main line.
- Reviewed merges: Restrict merge rights so that changes reach the protected branch only through a merge request, which leaves a history of who proposed and approved each change.
- Blocked direct pushes: Set push access to no one on the protected branch so that developers cannot bypass the review path.
- Force pushes disabled: Keep force pushes off unless explicitly allowed, so the commit history that supports flaw tracking is not rewritten.
- What it does not cover: It does not run tests, record test coverage decisions or track remediation of flaws found in testing. Those records must come from your test plan and defect process.
Confirm with your platform team which branches are protected, who holds maintainer rights, and whether the edition and settings you deploy match the documentation linked on this page.
Semgrep Community Edition scans source code for patterns that indicate defects or security weaknesses. It can run in CI/CD pipelines so that scans execute on each change, and the scan output becomes evidence of testing performed on the developer's code.
- Languages covered: Scanning supports C/C++, C#, Go, Java, JavaScript, TypeScript, Python, Ruby, Rust, PHP, Kotlin, Swift and Terraform, using community or custom rules.
- Pipeline evidence: Pipeline logs and stored findings show when scans ran and what they reported, which supports the assessor's test of whether testing occurs at a defined frequency.
- Custom rules: Organization-specific rules can encode your own secure coding requirements, so that the scan tests the criteria you defined.
- What it does not cover: It is static analysis only. It does not test running systems, and it does not cover languages outside the list unless you confirm separate support.
- License caveat: Semgrep Community Edition is licensed under LGPL-2.1-only. Have counsel confirm that your use, distribution and any modifications meet that license.
Confirm the rule sets in use, the languages in your repositories and how findings are triaged before you present scan output as SA-11 evidence.
Wazuh and Fleet both detect vulnerable software on hosts by matching installed software against vulnerability data. They do not test the developer's code, but they show whether the components in deployed systems have known flaws, which feeds the flaw remediation part of SA-11.
- Wazuh vulnerability detection: Each agent's software inventory is correlated with the Wazuh CTI vulnerability repository or a locally hosted offline copy, covering the operating system and installed applications of monitored endpoints (GPL-2.0-only).
- Fleet vulnerability detection: Installed software on enrolled hosts is matched against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV (MIT).
- Remediation records: Exported findings with dates and status show what was flagged and whether it was closed, supporting the verifiable remediation process the control describes.
- What it does not cover: Neither tool tests application logic or finds flaws in custom code, and neither decides whether a finding is a risk you accept.
- License caveat: Wazuh is GPL-2.0-only and Fleet is MIT. Confirm the license terms that apply to the version and deployment model you choose.
Confirm which hosts are in scope, how often inventories refresh, and whether an offline vulnerability copy is required in your environment.
What meeting SA-11 costs in money and effort
This table breaks the cost of meeting SA-11 into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. NIST does not estimate compliance costs, so use the table to shape your questions and quote requests rather than as a budget. The main takeaway is that the largest recurring costs come from flaw remediation and evidence upkeep, which scale with code base size, release frequency and the number of enhancements you select.
| Cost component | Who is paid and for what | One-time or recurring, and main drivers |
|---|---|---|
| Tooling and licenses | Vendors of commercial testing tools, or staff time to run open-source tools such as Semgrep Community Edition and GitLab Community Edition | Mostly recurring for commercial licenses. Open-source tools remove license spend but still need hosting and configuration. Drivers: number of repositories, languages and pipelines |
| Engineering time to write plans and wire tests | Internal developers and security engineers, or an implementation partner, to write the developer assessment plan and connect unit, integration, system and regression tests | Mostly one-time setup, then recurring upkeep. Drivers: code base size, number of teams, and how many SA-11 enhancements you select |
| Flaw triage and remediation labor | Developers and security staff who review scanner and test findings, decide severity and fix flaws through the tracked remediation process | Recurring and usually the largest line. Drivers: release frequency, dependency count, false positive rate and remediation deadlines you set |
| Evidence upkeep | Staff who keep test results, remediation tracking records, architecture documents and assessment plans current and retrievable | Recurring with every release. Drivers: audit cadence, number of systems in scope and how much evidence collection is automated |
| External penetration or assessment work | Independent testers hired for penetration testing or for the dynamic and threat modeling enhancements, paid by scope | Usually recurring per cycle. Drivers: application count, attack surface, number of environments and whether retests are included in the fixed scope |
| Independent auditor sampling | The independent assessor, who selects samples of plans, test results and remediation records to test the control | Recurring per assessment. Drivers: sample sizes chosen by the assessor, number of systems, and how well evidence is organized before testing starts |
| Internal review of contract terms | Procurement and legal staff who require developers and suppliers to provide testing and evidence in acquisition contracts | Mostly one-time per contract, repeated at renewal. Drivers: number of third-party developers and how much existing contract language already covers SA-11 |
Who owns SA-11 work: your team, a partner and the auditor
Your organization owns SA-11. The requirement sits with the developer, and when your teams build or modify software, your engineering and security leads decide what testing is performed, how deep it goes, which flaws must be fixed before release and who accepts residual risk. Those decisions cannot be delegated to a partner or an auditor.
- Assessment plan ownership: Your security lead approves the developer security testing plan, sets the testing frequency, depth and coverage, and records who may waive a finding.
- Test execution: Engineers write and maintain unit, integration, system and regression tests, and security test cases that run in your delivery pipeline.
- Flaw tracking: Your product owners triage findings, assign remediation and keep the tracking records that show when each flaw was closed and how it was verified.
- Internal review: Compliance staff check that test results, remediation records and plan revisions match what the SA-11 assessment procedures ask an assessor to examine.
Ask whether your team can name an accountable owner for each testing activity and produce the plan, results and tracking records without help from an outside party.
An implementation partner can take on the build work that supports SA-11. DeployOpen, for example, plans, implements, integrates and documents self-hosted open-source platforms inside your own infrastructure, and runs security testing as a separate service. A partner prepares the systems, pipelines and evidence; it does not decide your risk acceptance and does not issue an assessment result.
- Pipeline setup: A partner can configure self-hosted tools such as GitLab protected branches, Semgrep rules in CI/CD and vulnerability detection for deployed hosts.
- Plan and procedure drafting: A partner can draft the developer testing plan and runbooks for your review, based on your system boundary and development process.
- Evidence preparation: A partner can set up collection of test reports, scan outputs and remediation tickets so they are retained and easy to examine.
- External testing: Penetration tests and application security tests can be scoped to a partner under a written statement of work, with findings delivered to your team.
Ask for the written scope, the list of deliverables and a statement of which records remain under your control after the engagement ends.
The independent assessor tests whether SA-11 is implemented and produces the assessment result. Depending on your program, this may be an assessor for a FedRAMP independent assessment or an auditor working under another framework that cites SP 800-53. The assessor is independent of both your team and any partner that helped build the controls.
- Examination: The assessor reviews the developer security and privacy assessment plans, testing records and flaw remediation tracking records that the SA-11 procedures name as objects to examine.
- Interviews and testing: The assessor interviews developers and security staff and may run its own tests on the system.
- Independence: A partner that wrote the plan or ran the tests can supply evidence, but it cannot be the party that certifies the result.
- Reporting: Only the assessor issues the findings and assessment result for SA-11.
For FedRAMP Rev5 systems, confirm the assessment cadence and class requirements directly with the FedRAMP rules before engaging an assessor.
Where SA-11 programs usually fall short and how to close each gap
SA-11 programs rarely fail because teams do no testing. They fail because testing is not planned, not tied to releases, not verified after fixes, and not documented for components built or supplied by others. The cards below describe each gap as an illustrative pattern and the step that closes it.
Testing without a written plan
Teams run unit tests, scans and reviews, but no document states what is tested, how deeply, how often and by whom. SA-11 expects the developer to plan and run ongoing security and privacy assessments, so an assessor will ask for the plan first. Write a developer security assessment plan that names the test types, coverage expectations, frequency and responsible roles for each system, then check that the pipeline actually runs what the plan says.
Results not linked to releases
Scanners report findings and pipelines show green builds, but nobody can show which tests ran against which release. Assessors examine results by version, so a report without build identifiers cannot prove that a given release was tested. Configure the pipeline so each build records its commit, the test suites executed, the tool versions and the results, and keep those records with the release notes.
Flaws closed without verification
A ticket is marked resolved when the developer merges a patch, but no one retests the affected path or confirms the flaw is gone. SA-11 asks for flaws to be fixed through a verifiable remediation process, and assessors examine the tracking records for that proof. Require a retest or regression test linked to each flaw ticket, and make closure depend on that linked evidence rather than on the merge alone.
Vendor components without developer evidence
Commercial and open-source components enter the system with no testing record from their developers, and the program treats them as out of scope. SA-11 applies at every post-design stage, so the organization still needs evidence for what it integrates. Ask suppliers for their test summaries and known-flaw history during acquisition, and track vulnerabilities in the software inventory of deployed components so gaps are visible.
Enhancements selected without a reason
SA-11 has nine enhancements, and programs often either adopt all of them or none without recording why. Enhancements such as static analysis, dynamic analysis, threat modeling and penetration testing each carry a different cost and proof obligation. Document the selection for each system, citing the system categorization, risk assessment and any FedRAMP requirement that applies, and review the decision when the system changes.
How much effort SA-11 takes and whether to hire outside help
How long does meeting SA-11 take, and what drives the time?
The duration depends mostly on how much of the developer testing program already exists, how many systems and release pipelines are in scope, and how often code and configuration change. SA-11 asks the developer to plan assessments, run testing at a defined frequency, depth and coverage, keep evidence of results, and fix flaws through a verifiable process. Teams with pipelines that already run tests and track findings need less new work than teams that must design the plan from scratch. NIST does not set implementation timelines, so the duration should come from a written scope, not a general estimate. Ask for the number of systems, pipelines and release cadence to be listed in that scope before any date is agreed.
Can we meet SA-11 in-house without outside help?
Yes, in principle. NIST describes the Rev. 5 controls as flexible and implemented within an organization-wide risk management process, so the organization owns the control and can run it with its own staff. The work that usually needs skilled internal effort is writing the developer security assessment plan, defining testing frequency, depth and coverage, and setting up flaw tracking that links findings to remediation. Teams without in-house application security skills often bring in help for those design decisions while keeping ownership of the plan and its approval. An independent assessor will not accept a plan that exists only on paper, so confirm the team can run the plan for a full cycle.
What does the work need from our engineering and security teams?
The work needs time from several roles, and the largest share falls on people who already own build and release processes. Expect involvement from:
- Engineering leads who define test coverage for each system and agree on what blocks a release
- Platform or DevOps engineers who wire scanners and test stages into CI/CD pipelines
- Security staff who triage findings, set severity handling and review remediation records
- Product owners who accept risk when a flaw cannot be fixed on schedule
The evidence trail matters as much as the tests, so someone must own the flaw tracking records from the first sprint.
Can a partner take over SA-11 testing or evidence preparation?
A partner can take on defined parts of the work, but accountability stays with the organization. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside the client's own infrastructure, and runs security testing. It can build the test stages, configure tools such as Semgrep Community Edition in pipelines, and organize remediation evidence for review. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or certifications, and independent assessors make that determination. Most engagements are fixed-scope, so the written scope should name which testing, tooling and evidence tasks transfer, and who signs off each one.
What will an auditor sample when testing SA-11?
An assessor works from the assessment procedures in SP 800-53A, which give determination statements and examine, interview and test methods for each control. For SA-11, the examine objects named in that procedure include the developer's security and privacy assessment plans, flaw and remediation tracking records, and the architecture documents the testing relates to. Expect the assessor to sample a set of releases or systems and ask for the plan, the test results for those releases, the findings raised, and the records showing each flaw was remediated or formally accepted. They will also interview engineers about how testing is run. Keep records consistent across all of these so any sampled item can be traced end to end.
How do FedRAMP Class C and D change the SA-11 work?
FedRAMP's Rev5 baselines require SA-11, SA-11(1) and SA-11(2) at Classes C and D, and its annual independent assessment rule requires SA-11(1) at those classes to be included in a FedRAMP independent assessment at least once a year. Those requirements add the enhancements to the base control, so the program must cover static and dynamic analysis, threat modeling and penetration testing, not only functional testing. The recurring cost rises because the assessment must be repeated annually and the evidence must be kept current across the year. Confirm the exact requirements for your class in the current FedRAMP rules and in a written scope with your assessor before planning the work.
How DeployOpen scopes SA-11 and prepares its evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and it prepares the developer testing records that SA-11 asks for. The organization owns its controls and developer obligations, and only an independent assessor issues assessment results.
How we scope
- The written scope names which systems, pipelines and developers fall under SA-11 testing before any work starts.
- It records the testing frequency, depth and coverage the organization sets, along with the SA-11 parameters it selects.
- Scope also states whether SA-11(1), SA-11(2) or other enhancements apply, and which evidence owners will supply.
How we build
- We configure protected branches, required reviews and CI jobs so each change passes defined security test stages.
- We set up static analysis such as Semgrep in pipelines, with rule sets chosen and version-controlled by the client.
- We help define a testing plan covering unit, integration, system and regression tests, with results stored as retrievable records.
How we hand over
- Handover includes the developer security testing plan, pipeline configuration files and a record of how each test type runs.
- Flaw tracking workflows link findings to remediation tickets, so the client can show who fixed each defect and when.
- Assessor-ready packages map each SA-11 determination statement to the artifacts that address it, for the client's assessor to review.
How we support
- Ongoing support and upgrades of testing tools are available as a retainer, scoped in writing.
- Retainers can cover periodic review of test coverage as the codebase, tooling or release process changes.
- Security testing and penetration testing of the platform can be scoped separately, with results delivered to the client.
