SC.L2-3.13.2 Security engineering: requirements and evidence

SC.L2-3.13.2 security engineering: what the requirement asks for

If you are a defense contractor that stores, processes or transmits CUI, you must prove SC.L2-3.13.2 for that system before you can claim Level 2 status. The requirement asks your organization to identify architectural designs, software development techniques and systems engineering principles that promote effective information security, and then to employ them within your organizational systems. It is a 5-point requirement. If it is scored NOT MET, it is subtracted from the maximum score of 110, and because it is worth more than 1 point it cannot be placed on a plan of action and milestones (POA&M). It must be MET outright to reach Conditional or Final Level 2 status.

The wording you will be assessed against is the NIST SP 800-171 Revision 2 text that CMMC incorporates, not the Revision 3 text NIST published later. The assessment objectives come from NIST SP 800-171A (June 2018), which splits the requirement into six objectives covering both the identification and the employment steps. The requirement is hard because it does not name a product. An assessor will not accept a firewall or a code scanner as proof on its own. You need a documented, reasoned set of principles that fit your system, such as the ones the CMMC Assessment Guide points to in NIST SP 800-160, along with evidence that you applied them to the system's design and development.

The suspension of CMMC Phase II on 13 July 2026 does not remove this requirement. Phase I self-assessments, SPRS postings and the DFARS 252.204-7012 obligations remain in place, so your Level 2 self-assessment score and the SPRS entry built from it still depend on whether SC.L2-3.13.2 is MET. Confirm the current status of the rule and assessment timing with the Department of War and your contracting officer, because the schedule has changed more than once. Whatever the timing, you should be ready to show a reasoned set of principles and the records that prove they were used.

Where security engineering reaches in a CUI environment

SC.L2-3.13.2 applies to every system in the assessed CUI boundary, so the scoping decisions that matter are the ones that determine which systems design, build or change security-relevant architecture. Each card below names one scope area and the decision that brings it in or out of the work an assessor will examine.

Enclave and boundary architecture

The CUI enclave is where architecture decisions are most concentrated. Decide whether the enclave is a dedicated environment or a segment of a shared network, and who approved that design. An assessor will expect the security architecture documentation to show why the enclave's shape was chosen, not only that it exists. Check that every system that stores, processes or transmits CUI, and every system that can reach it, is inside the documented boundary.

Identity and authentication design

Decide whether the identity provider sits inside the CUI boundary or is an external service that stores user and group data. Either choice brings a design decision into scope, because identity flows determine who can reach the enclave and how administrative roles are separated. Confirm which identity components a third party operates and where their engineering decisions are documented.

Cloud tenancy and infrastructure as code

Cloud accounts, subscriptions and tenants that host CUI are in scope when their configuration was designed to protect it. Infrastructure as code templates that define network rules, storage encryption and logging settings are engineering artifacts that an assessor may review. Decide whether a shared tenant with CUI workloads can be separated cleanly, and record the reasoning for that choice.

Custom applications and CI/CD pipelines

Custom code that handles CUI, and the pipelines that build and deploy it, are included when they affect how security is engineered into the system. A build server that pulls dependencies from outside the boundary or that deploys to production without review changes the security design. Decide whether the pipeline is part of the CUI boundary or is treated as an external source with controlled interfaces, and document that decision.

Third parties and managed service providers

A managed service provider or software vendor that designs, configures or changes an in-scope system brings its engineering decisions into your assessment. Decide whether each provider is an external service that handles CUI, a provider that only supports systems you own, or a party outside the boundary. Ask each provider for documentation of the security engineering principles it applied, and confirm that its responsibilities appear in your system security plan.

System security plan alignment

The system security plan describes the systems in scope and how each requirement is met, so it is where scope decisions become testable statements. Each architecture decision above should appear in the plan with its rationale and the systems it covers. An assessor compares the plan with the operating environment, so any gap between the two will surface as a finding against the requirement.

How an assessor tests security engineering against SP 800-171A

This table walks through the six assessment objectives NIST SP 800-171A sets for SC.L2-3.13.2, with the test approach, the evidence an assessor requests and the findings that most often keep a requirement from being MET. Read each row as one step of the assessor's work: the objectives are judged together, and a single unsatisfied objective means the requirement is NOT MET.

Assessment objective	Test approach and evidence requested	Common findings
Architectural designs are identified	Assessor reviews security architecture documentation and checks that it covers the system boundary, components, trust zones and data flows covered by the SSP.	Architecture is described only in a diagram that predates recent system changes, or it omits cloud services and remote access paths.
Architectural designs are employed	Assessor traces the documented architecture to the deployed configuration and to the requirements and specifications the system was built against.	The design shows a segmented architecture, but the running environment has flat networks or systems that were never placed in the documented zones.
Software development techniques are identified	Assessor asks which development techniques apply, such as secure coding standards, code review and static analysis, and reviews the documented selection and its rationale.	Techniques are listed generically in a policy, with no statement of which ones apply to the organization's own systems or custom code.
Software development techniques are employed	Assessor samples recent development or change records, such as pull request reviews, protected branch settings and scan results, to confirm the selected techniques were used.	Protected branch settings are configured in the tool but reviews and scan results are missing for recent merges, or scans run but findings are never triaged.
Systems engineering principles are identified	Assessor reviews the procedures that name the engineering principles in use, which may draw on NIST SP 800-160, and confirms the organization chose the principles suited to its systems.	Principles are copied from a reference without any link to the organization's own system requirements or risk decisions.
Systems engineering principles are employed, with tests of the processes	Assessor tests the process end to end: selects a representative system change, checks the security analysis it triggered, and reviews SSP development and review records showing the principles were applied and updated over time. Evidence must be final form, not drafts.	Principles are named in the procedures and SSP but never applied to a system change. Example (illustrative): a firewall rule change is approved with no security impact review and the SSP architecture section is unchanged.

How to implement security engineering principles in six steps

This sequence turns SC.L2-3.13.2 from a statement of intent into a documented, applied and tested practice, with each step leaving an artifact an assessor can examine.

Select the principles that fit the CUI system
The engineer and compliance lead review the systems that store, process or transmit CUI and choose the architectural designs, development techniques and systems engineering principles that suit them. NIST SP 800-160 is a useful reference for this selection, but the CMMC Assessment Guide leaves the choice to the organization, so each principle chosen should have a short reason tied to the system. The output is a principles register that names each principle, the systems it applies to, the owner and the reason it was accepted or set aside. The step is done when every CUI system is covered and the register has been approved by the person accountable for the system security plan.
Document the security architecture
The security architect describes how the CUI system is built, including its components, data flows, trust zones, external connections and the places where the chosen principles take effect, such as separation between user and administrative functions or the placement of security checks in the design. This architecture document is one of the potential assessment objects named in NIST SP 800-171A for this requirement, so it should show the actual system and not an idealized diagram. The step is complete when the document matches the current environment and a second engineer has walked the diagram against the running system.
Define security requirements and specifications
The team converts the principles and the architecture into written security requirements and specifications for each system component, covering items such as authentication behavior, logging expectations, input handling and data protection. Each requirement should be traceable to a principle in the register and to a control in the system security plan, which makes it easier to show that the principles were applied and not merely listed. The output is a requirements specification with traceability entries. The step is done when every principle in the register maps to at least one specification, and gaps are recorded as open items with owners.
Build the principles into development and change
Engineering leads add the principles to the development and change process so that new code, infrastructure changes and configuration updates are checked against them before release. Practical controls include protected branches that require review before code reaches the main line, automated static analysis in the build pipeline, and documented approval for design changes. Open-source options such as GitLab Community Edition protected branches and Semgrep Community Edition scanning in CI/CD can supply part of this evidence, but the organization should confirm the features and rules it needs in its own environment. The output is a documented change procedure and pipeline configuration. The step is done when a sample change shows the checks running and the approval recorded.
Review and record decisions in the SSP
Designated reviewers check the architecture, specifications and change records against the principles at a set cadence and whenever the system changes significantly. Each decision, exception and deviation is written into the system security plan with its date, approver and rationale, so the SSP describes how the principles are actually used. Wiki or documentation tools with version history, such as XWiki, can keep a record of who changed what and when, and role-based permissions in tools such as BookStack can limit who may approve entries. The output is a reviewed SSP section and a change log that an assessor can follow. The step is done when the most recent review is dated, signed off and linked to the artifacts it examined.
Test that the process runs as written
The compliance lead tests whether the process operates in practice, not only on paper. This means selecting recent changes, architecture reviews and design decisions, then confirming that the principles were considered, the approvals happened and any exceptions were recorded and handled. Assessors test the processes that apply these principles, so the test should follow the same logic and produce a written result listing any failures and the corrective action taken. The output is a dated test record with findings and remediation items. The step is complete when the sample tests pass or each failure has an owner and a tracked fix, and the results feed back into the principles register for the next cycle.

Security engineering evidence that passes an assessment

SC.L2-3.13.2 is a process requirement, so assessors look for records that show the organization identified engineering principles and applied them to its system. The six artifacts below are the ones that usually carry that proof. Each one needs a clear owner, a version history and dated approvals so the evidence still reflects the system at assessment time.

Security architecture documentation

This is the set of diagrams and narrative showing how the system is built, where trust boundaries sit, which components handle CUI and how data moves between them. An assessor uses it to check that architectural decisions were deliberate and tied to the boundary and segmentation controls. Confirm that the documents match the live environment, including cloud accounts, enclaves and remote access paths. A diagram that shows a network the system no longer uses will be noticed quickly. Keep the diagrams in source-controlled form where possible so each change has an author and a date.

Principles register or engineering standard

This is the document that names the security engineering principles the organization chose to apply, such as least privilege, defense in depth and fail-safe defaults, and states why each suits its system. NIST SP 800-160 is a common reference, but the organization decides which principles fit. Assessors check that the list is specific to the environment rather than copied from a reference. Record the owner, the approval date and the review cycle, and note any principle the organization decided not to apply along with its reason.

System requirements and specifications

Requirements and specifications turn the principles into testable statements about the system, for example which services must authenticate, which ports are permitted and how data is protected at each hop. Assessors trace these statements back to the principles register and forward to the design and test records. Gaps usually appear where a requirement exists only in a ticket or a chat thread. Keep each requirement with an identifier, a status and a link to the control it supports, and retire requirements in writing when the system changes.

Change and design review records

Design reviews and change approvals show that engineering principles were applied when the system was built or altered. A useful record names the change, the security questions raised, the reviewer, the decision and any follow-up. Assessors sample recent changes and ask whether the security review happened before deployment. Pull requests and merge approvals can serve as this record when the workflow requires a security reviewer for changes touching CUI systems. Confirm that reviewers are independent of the author for those changes.

SSP sections and review history

The system security plan describes how the organization meets each requirement, including SC.L2-3.13.2. The section for this requirement should name the architectural designs and engineering principles in use and point to the supporting documents. Assessors check the SSP's version history, the dated approvals and whether the text matches what they observe. Stale language, such as a plan that describes a retired architecture, is a common finding. Record each review with its date, reviewer and the changes made.

Test records showing the process ran

Test records show that the engineering process operated over time, not only that it was written down. Examples include architecture reviews completed on schedule, security test results fed back into design, and tabletop or design walkthroughs that changed a decision. Assessors ask for a sample across the assessment period and check that findings were tracked to closure. Store results with dates and the people involved so the history can be shown without reconstruction. Ask the assessor early which sample window they expect.

Open-source tools that support security engineering evidence

GitLab Community Edition supports protected branches, which control who can change the code that becomes part of your system. For SC.L2-3.13.2, the relevant point is that security engineering decisions made in code, such as boundary configuration or secure defaults, should only enter the main line of development through a reviewed and recorded path. Protected branches help create that path. The license for GitLab Community Edition is MIT, but confirm the license terms for the version you deploy.

Restricted push and merge roles: Maintainers can limit which roles may push or merge to a branch, so changes to security-relevant code follow a defined approval route.
Blocked direct pushes: Setting push access to no one forces changes through merge requests, which leaves a reviewable record.
Force pushes disabled: Keeping force pushes off prevents history on protected branches from being rewritten.
Configuration exports: Screenshots or exported settings of branch protection rules can show the assessor the rules as configured on a given date.

The tool cannot prove that architectural designs were identified or that engineering principles were applied. It only shows how code changes were controlled. Check with your assessor which branch and merge records they will accept as evidence of the process.

What security engineering costs to meet

This table breaks down the cost components of meeting SC.L2-3.13.2 by who is paid, whether the cost is one-time or recurring, and what drives it up or down. Use it to shape a written scope and to compare quotes, since the largest costs are internal engineering time and evidence upkeep rather than software licenses. No price figures are given because none are supplied for this requirement.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it and what to ask for
Architecture and principle decisions	Internal architects, with optional outside security engineers	One-time, then recurring on change	Number of systems and trust boundaries. Ask the partner to name the principles selected and the design documents produced.
Development process changes	Internal engineering leads and development teams	One-time setup, recurring use	Number of custom applications and release frequency. Ask what secure development steps are added to the pipeline and who owns them.
Tooling and licenses	Software vendors or none for open source	Mostly recurring for commercial tools	Self-hosted open-source tools remove license spend but not labor for setup, tuning and upkeep. Ask for a list of tools and their license terms.
Evidence upkeep	Internal compliance and engineering staff	Recurring	Change frequency and the number of documents to keep current. Ask how records of design reviews and SSP updates will be kept in final form.
External architecture review	Independent security engineering consultant, if used	One-time, plus periodic	Architecture complexity and existing documentation quality. Ask for review scope, deliverables and whether findings are tracked to closure.
Assessor sampling effort	Internal staff supporting the assessor; assessor fees paid to the certifying body	Recurring per assessment cycle	Number of systems sampled and how quickly evidence can be produced. Ask the assessor what artifacts they will request for this objective.
Remediation of design gaps	Internal engineering, or a partner under fixed scope	One-time, sometimes recurring	Age of existing architecture and number of legacy components. Ask for a gap list before work is priced.

Who owns the design, who prepares evidence and who assesses it

Your organization owns SC.L2-3.13.2. It decides which architectural designs, software development techniques and systems engineering principles apply to its systems, and it is accountable for applying them. The CMMC Assessment Guide points to NIST SP 800-160 as a source of design principles and leaves the choice of principles to the organization, so the decisions have to be written down by the people who run the system.

Principle selection: Name the security engineering principles you adopt, the reason each fits your systems, and who approved them.
Architecture decisions: Keep the architecture documentation current, including the security architecture for the CUI environment and its boundaries.
Process ownership: Assign an accountable owner for applying the principles in procurement, development and change work.
Records: Keep SSP development and review records that show the principles were applied and revisited.
Sign-off: Make sure leadership accepts the final documents, since an assessor will test the process as well as the artifacts.

Before any assessment, confirm that each principle you claim has a named owner and a dated record of use.

Where security engineering evidence usually falls short

Most SC.L2-3.13.2 findings do not come from missing principles. They come from principles that exist on paper but never reach a system change, a design record or a shared document. The cards below describe the gaps assessors most often run into and the check that closes each one.

Principles stated but never applied

The security policy lists secure design principles such as least privilege, defense in depth and fail-safe defaults, but no system change record shows them being applied. An assessor testing SC.L2-3.13.2 will ask for a recent change where a design decision was made against a named principle. Check whether change tickets or architecture decision records reference the principles and whether the reasoning is recorded for at least a sample of changes.

Architecture documents written after the fact

Diagrams and design documents are produced at audit time and describe the system as the team wishes it had been built. Assessors compare these documents against configuration baselines, network diagrams and deployed components. Check the document dates against the change history, and confirm that the architecture was reviewed when the system last changed.

Development process without review records

Teams may describe peer review and secure coding practices, but the repository shows direct pushes or merges without approval. Review evidence is what turns a stated process into a tested one. Check protected branch settings, merge request approvals and any static analysis results retained from the pipeline.

SSP sections out of step with the architecture

The system security plan describes boundaries, components and data flows that no longer match the deployed environment. For SC.L2-3.13.2, the mismatch shows that design principles are not tied to the system being assessed. Check that each SSP section that describes architecture is reconciled with current diagrams and inventories, and that the reconciliation date is recorded.

Managed provider decisions with no inherited evidence

A managed service provider makes design decisions for platforms, hosting or identity, but the organization holds no evidence of them. Assessors will ask who made each decision and what proof the organization has. Check the service agreement for responsibility matrices, request design documentation from the provider, and confirm which parts of the security engineering evidence the provider can supply.

Documents left in draft at assessment time

Architecture standards, design reviews and engineering procedures are still marked draft when the assessment begins. Under the CMMC rules, evidence must be in final form to count, so a requirement backed only by drafts is not met. Check version control and approval records for every document that supports the requirement, and finalize them before the assessment window.

How much work and cost does SC.L2-3.13.2 need from us

How much effort does SC.L2-3.13.2 take compared with other CUI requirements?

SC.L2-3.13.2 usually takes more documentation and governance effort than hands-on configuration, because it asks you to show that security engineering principles are chosen, applied and reviewed for your system. It is worth 5 points under the CMMC Scoring Methodology, so it cannot go on a POA&M and must be MET. Effort depends on how much architecture documentation already exists. Teams with a current system security plan and design records often need less. Teams that rely on informal knowledge will spend more time writing down decisions they already made. The cost section explains how these drivers translate into budget.

Can a small team meet SC.L2-3.13.2 without outside help?

Yes, a small team can meet it without an outside partner if one person owns the architecture, the team can name the principles it applies, and the decisions are written down. The assessment objectives focus on identifying and then employing architectural designs, development techniques and engineering principles. A small team should expect to assign an owner, select a reference such as NIST SP 800-160, and record how each principle shows up in the system. Outside help is most useful when the team lacks time to write design records or needs an independent review of gaps before an assessment. The CMMC Assessment Guide notes that organizations decide which principles fit their systems, so the choice is yours to justify.

What does the work need from engineering and leadership?

Engineering supplies the technical substance, and leadership supplies the decision and the accountability. Engineers must describe the architecture, document secure development practices and show how design choices protect CUI. Leadership must approve which principles apply, assign an accountable owner and fund the review cycle. Typical engineering inputs include network diagrams, data flow records, code review rules and deployment pipeline settings. Leadership inputs include policy approval and sign-off on the scope of the assessment. If either side is missing, the evidence usually stalls at draft status, and drafts do not satisfy the assessment objectives.

How long does it take to produce defensible evidence for SC.L2-3.13.2?

The timeline depends on how much of your architecture is already documented and how often your engineering decisions are reviewed. The main delay is usually not building controls but getting final, approved records that match what the system actually does. Plan time for drafting design documents, reviewing them with engineers, approving them, and then testing whether the development process applies them. Ask any partner to show a schedule tied to named deliverables and review dates rather than a general estimate. The CMMC rule requires evidence in final form, so build review time into the plan from the start.

Can a managed service provider inherit SC.L2-3.13.2 from its platform?

A managed service provider can share some of the work but cannot transfer accountability for your CUI environment. If the provider operates the platform, its design records may cover the architecture it runs, and you can reference them in your own system security plan. You still need to show how your organization selected and applied the principles for the parts you control, such as your development practices, configurations and boundary decisions. Review the provider's documentation against the assessment objectives and confirm in writing which objectives it covers. Any gaps stay with you, and the assessor will test your scope, not the provider's marketing.

Does a self-assessment or certification assessment change the evidence needed?

The evidence standard is the same for both, because each tests the NIST SP 800-171A assessment objectives for SC.L2-3.13.2. A self-assessment lets your organization judge whether it meets the objectives and then record the result. A certification assessment is performed by an authorized or accredited C3PAO, which tests the evidence independently. The difference lies in who checks the work and how formally the results are reported. Program status is also a separate matter, as the Department of War has suspended Phase II, so confirm the current requirement before planning around a certification date. Prepare the same evidence set either way.

What should we ask a partner to put in a written scope?

Ask for a written scope that names the systems covered, the assessment objectives addressed and the evidence each deliverable will produce. Good scope items include an architecture review of the CUI environment, a list of engineering principles selected with reasons, updates to the system security plan, a review of secure development practices and a plan for final sign-off. Ask who owns each deliverable, what your team must provide, and how revisions are handled. DeployOpen works on fixed scopes agreed in writing before work starts and does not publish a price list, so the quote follows from the scope. Use the cost section to see which scope items drive effort.

How DeployOpen scopes and prepares security engineering evidence

DeployOpen works on SC.L2-3.13.2 by helping you document the security engineering principles your systems already follow, then building and hardening the open-source platforms and records that show those principles in use. The organization owns its architecture decisions and controls, and an independent assessor makes the final determination.

How we scope

Engagements are fixed-scope, with the systems, environments and deliverables for SC.L2-3.13.2 agreed in writing before work starts.
We confirm which architectural designs and engineering principles your organization has chosen to apply, since the requirement leaves that choice to you.
We identify the security architecture documents, system specifications and SSP records that a assessor would examine for this requirement.

How we build

We configure self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks so architecture decisions are enforced in the system itself.
We set up protected branches in GitLab Community Edition so code changes to security-relevant components follow an approved, reviewed path.
We run Semgrep Community Edition in CI/CD pipelines to scan repositories continuously against security rules agreed in the scope.

How we hand over

We document the design principles, procedures and review steps in wiki and knowledge base tools such as XWiki, with version history kept for each change.
We set role-based permissions in BookStack so the people who approve and maintain security engineering procedures are clearly identified and recorded.
We deliver the evidence package in final form, mapped to the six assessment objectives, so your team can present it to the assessor as completed records.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so the design principles and tooling stay current after handover.
Ask us to confirm which parts of the evidence need periodic review, and agree on who in your organization owns each review.
Confirm with your assessor and your organization's own environment which evidence formats they will accept before the scope is finalized.