Security Engineering

The six objectives are one structure: identify three things, then employ them.

Objectives [a], [b], and [c] ask you to name the architectural designs, software development techniques, and systems engineering principles you follow. Objectives [d], [e], and [f] ask for proof that each named item shows up in the system. Write the identification document first. Without it the employment evidence has nothing to point at.

Not developing software answers [b] and [e], and nothing else.

Buying commercial software instead of building your own is a legitimate software development technique: state it under [b], and your procurement practice covers [e]. The other four objectives still stand. Architectural designs and systems engineering principles apply to any IT footprint, including a company that has never written a line of code.

Adopt principles from a published source instead of inventing them.

The security design principles in NIST SP 800-160 give you a menu. Pick the ones that fit and cite them. CIS Benchmarks or STIGs, both published hardening guides, serve as engineering principles and do double duty as the configuration settings CM.L2-3.4.2 asks for. Layered protection, least functionality, and deny by default are principles you already practice. The work is writing down which ones you chose.

Show employment through decisions you already made.

The cloud tenant you selected, the baseline that hardens your endpoints, the segmentation that isolates CUI (Controlled Unclassified Information): each is a design decision. For [d], [e], and [f], connect each adopted principle to the decision it drove. The evidence is a page in your system security plan tracing each principle to its implementation. That plan is the document describing how your system meets each requirement.