SEA-01: Secure Engineering Principles
Mechanisms exist to facilitate the implementation of industry-recognized cybersecurity and data protection practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).
Control Question: Does the organization facilitate the implementation of industry-recognized cybersecurity and data protection practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS)?
General (63)
| Framework | Mapping Values |
|---|---|
| AICPA TSC 2017:2022 (used for SOC 2) (source) | CC2.2 CC3.2 CC5.1 CC5.2 CC6.1-POF2 CC8.1-POF15 CC8.1-POF18 |
| CIS CSC 8.1 | 12.2 12.6 16 16.10 |
| CIS CSC 8.1 IG2 | 12.2 12.6 16.10 |
| CIS CSC 8.1 IG3 | 12.2 12.6 16.10 |
| COBIT 2019 | APO03.01 APO03.02 APO03.03 APO03.04 APO03.05 APO04.05 |
| COSO 2017 | Principle 7 Principle 10 Principle 11 Principle 14 Principle 17 |
| CSA CCM 4 | DSP-07 DSP-08 IVS-01 IVS-09 |
| CSA IoT SCF 2 | CLS-05 GVN-01 GVN-02 SWS-04 |
| ENISA 2.0 | SO12 |
| Generally Accepted Privacy Principles (GAPP) | 4.2.3 6.2.2 7.2.2 7.2.3 |
| GovRAMP Low | SC-01 SI-01 |
| GovRAMP Low+ | SC-01 SI-01 |
| GovRAMP Moderate | SA-08 SC-01 SC-07(18) SI-01 |
| GovRAMP High | SA-08 SC-01 SC-07(18) SI-01 |
| IEC 62443-4-2 2019 | CCSC 1 (4.2) |
| IMO Maritime Cyber Risk Management | 3.2 3.5.5 3.8 |
| ISO/SAE 21434 2021 | RC-05-10 |
| ISO 27002 2022 | 8.12 8.26 8.27 |
| ISO 27017 2015 | 14.1.2 14.2.5 |
| ISO 27018 2014 | A.10.1 A.10.4 A.10.5 A.10.6 |
| MITRE ATT&CK 10 | T1005, T1025, T1041, T1048, T1048.002, T1048.003, T1052, T1052.001, T1078, T1078.001, T1078.003, T1078.004, T1134.005, T1190, T1213.003, T1482, T1547.011, T1567, T1574.002 |
| MPA Content Security Program 5.1 | OR-1.0 |
| NAIC Insurance Data Security Model Law (MDL-668) | 4.D(2)(b) |
| NIST AI 100-1 (AI RMF) 1.0 | GOVERN 1.2 |
| NIST Privacy Framework 1.0 | ID.DE-P4 GV.PO-P2 CT.PO-P1 CT.DM-P7 CT.DM-P8 CM.AW-P3 |
| NIST 800-37 R2 | P-15 |
| NIST 800-39 | 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 |
| NIST 800-53 R4 | AR-7 SA-8 SA-13 SC-1 SC-7(18) SI-1 |
| NIST 800-53 R4 (low) | SC-1 SI-1 |
| NIST 800-53 R4 (moderate) | SA-8 SC-1 SI-1 |
| NIST 800-53 R4 (high) | SA-8 SC-1 SC-7(18) SI-1 |
| NIST 800-53 R5 (source) | PT-1 SA-8 SC-1 SC-7(18) SI-1 SA-15(5) |
| NIST 800-53B R5 (privacy) (source) | PT-1 SI-1 |
| NIST 800-53B R5 (low) (source) | SA-8 SC-1 SI-1 |
| NIST 800-53B R5 (moderate) (source) | SA-8 SC-1 SI-1 |
| NIST 800-53B R5 (high) (source) | SA-8 SC-1 SC-7(18) SI-1 |
| NIST 800-53 R5 (NOC) (source) | SA-15(5) |
| NIST 800-82 R3 LOW OT Overlay | SA-8 SC-1 SI-1 |
| NIST 800-82 R3 MODERATE OT Overlay | SA-8 SC-1 SC-7(18) SI-1 |
| NIST 800-82 R3 HIGH OT Overlay | SA-8 SC-1 SC-7(18) SI-1 |
| NIST 800-160 | 2.1 2.2 2.3 2.4 |
| NIST 800-161 R1 | PT-1 SA-8 SC-1 SI-1 |
| NIST 800-161 R1 C-SCRM Baseline | SA-8 SC-1 SI-1 |
| NIST 800-161 R1 Level 1 | SA-8 SC-1 SI-1 |
| NIST 800-161 R1 Level 2 | SA-8 SC-1 SI-1 |
| NIST 800-161 R1 Level 3 | SA-8 SC-1 SI-1 |
| NIST 800-171 R2 (source) | 3.13.2 |
| NIST 800-171A (source) | 3.13.2[a] 3.13.2[c] 3.13.2[d] 3.13.2[f] |
| NIST 800-171 R3 (source) | 03.01.12.a 03.01.16.a 03.01.16.b 03.01.16.c 03.01.18.a 03.13.01.c 03.16.01 |
| NIST 800-171A R3 (source) | A.03.16.01.ODP[01] |
| NIST CSF 2.0 (source) | PR.IR PR.IR-01 PR.IR-03 |
| OWASP Top 10 2021 | A01:2021 A04:2021 A05:2021 |
| PCI DSS 4.0.1 (source) | 1.2 6.1 6.2 6.2.1 8.5 8.5.1 |
| PCI DSS 4.0.1 SAQ A-EP (source) | 6.2.1 8.5.1 |
| PCI DSS 4.0.1 SAQ C (source) | 6.2.1 8.5.1 |
| PCI DSS 4.0.1 SAQ D Merchant (source) | 6.2.1 8.5.1 |
| PCI DSS 4.0.1 SAQ D Service Provider (source) | 6.2.1 8.5.1 |
| SWIFT CSF 2023 | 1.3 2.9 |
| TISAX ISA 6 | 5.3.1 |
| SCF CORE Mergers, Acquisitions & Divestitures (MA&D) | SEA-01 |
| SCF CORE ESP Level 1 Foundational | SEA-01 |
| SCF CORE ESP Level 2 Critical Infrastructure | SEA-01 |
| SCF CORE ESP Level 3 Advanced Threats | SEA-01 |
US (44)
| Framework | Mapping Values |
|---|---|
| US C2M2 2.1 | ARCHITECTURE-1.A.MIL1 ARCHITECTURE-1.B.MIL2 ARCHITECTURE-1.C.MIL2 ARCHITECTURE-1.D.MIL2 ARCHITECTURE-1.E.MIL2 ARCHITECTURE-1.F.MIL2 ARCHITECTURE-1.I.MIL3 ARCHITECTURE-1.J.MIL3 ARCHITECTURE-1.K.MIL3 |
| US CERT RMM 1.2 | EXD:SG3.SP2 EXD:SG3.SP4 EXD:SG4.SP1 RRD:SG2.SP1 RRD:SG3.SP2 RRD:SG3.SP3 RTSE:SG1.SP2 RTSE:SG1.SP3 TM:SG1.SP2 TM:SG2.SP1 |
| US CISA CPG 2022 | 1.E |
| US CJIS Security Policy 5.9.3 (source) | 5.10.3.2 SI-1 |
| US CMMC 2.0 Level 2 (source) | SC.L2-3.13.2 |
| US CMMC 2.0 Level 3 (source) | SC.L2-3.13.2 |
| US CMS MARS-E 2.0 | AR-7 SA-8 SC-1 SC-7(18) SI-1 |
| US Data Privacy Framework (DPF) | II.4.a |
| US DoD Zero Trust Reference Architecture 2.0 | 3.0 |
| US DHS CISA TIC 3.0 | 3.UNI.RESIL |
| US DHS ZTCF | DEV-01 NTW-02 |
| US FDA 21 CFR Part 11 | 11.30 11.50 11.70 11.100 11.100(a) 11.100(b) |
| US FedRAMP R4 | SC-1 SA-8 SC-7(18) SI-1 |
| US FedRAMP R4 (low) | SC-1 SI-1 |
| US FedRAMP R4 (moderate) | SC-1 SA-8 SC-7(18) SI-1 |
| US FedRAMP R4 (high) | SC-1 SA-8 SC-7(18) SI-1 |
| US FedRAMP R4 (LI-SaaS) | SC-1 SI-1 |
| US FedRAMP R5 (source) | SA-8 SC-1 SC-7(18) SI-1 |
| US FedRAMP R5 (low) (source) | SA-8 SC-1 SI-1 |
| US FedRAMP R5 (moderate) (source) | SA-8 SC-1 SC-7(18) SI-1 |
| US FedRAMP R5 (high) (source) | SA-8 SC-1 SC-7(18) SI-1 |
| US FedRAMP R5 (LI-SaaS) (source) | SA-8 SC-1 SI-1 |
| US FTC Act | §45(a) §45b(d)(1) |
| US GLBA CFR 314 2023 (source) | 314.4(c) |
| US HIPAA Administrative Simplification 2013 (source) | 164.306(b)(1) |
| US HIPAA Security Rule / NIST SP 800-66 R2 (source) | 164.306(b)(1) |
| US HIPAA HICP Small Practice | 1.S.A 2.S.A 3.S.A 5.S.A 5.S.B 5.S.C 6.S.A 6.S.C 9.S.A |
| US HIPAA HICP Medium Practice | 1.M.A 5.M.B 9.M.B |
| US HIPAA HICP Large Practice | 1.M.A 5.M.B 9.M.B 1.L.A |
| US IRS 1075 | PT-1 SA-8 SC-1 SC-7(18) SI-1 |
| US NERC CIP 2024 (source) | CIP-003-8 1.1.4 |
| US NISPOM 2020 | 8-101 8-302 8-311 |
| US NNPI (unclass) | 16.2 |
| US SSA EIESR 8.0 | 5.6 |
| US - CA SB327 | 1798.91.04(a) 1798.91.04(a)(1) 1798.91.04(a)(2) 1798.91.04(a)(3) 1798.91.04(b) 1798.91.04(b)(1) 1798.91.04(b)(2) |
| US - CA CCPA 2025 | 7123(c)(5)(B) |
| US - CO Colorado Privacy Act | 6-1-1305(4) 6-1-1308(5) |
| US - NY DFS 23 NYCRR500 2023 Amd 2 | 500.2(b)(2) |
| US - NY SHIELD Act S5575B | 4(2)(b)(ii)(B)(1) 4(2)(b)(ii)(B)(2) 4(2)(b)(ii)(B)(3) 4(2)(b)(ii)(B)(4) |
| US - TX BC521 | 521.052 |
| US - TX DIR Control Standards 2.0 | SA-8 SC-1 SI-1 |
| US - TX TX-RAMP Level 1 | SC-1 SI-1 |
| US - TX TX-RAMP Level 2 | SA-8 SC-1 SC-7(18) SI-1 |
| US - VT Act 171 of 2018 | 2447(a) 2447(a)(1) 2447(a)(1)(A) 2447(a)(1)(B) 2447(a)(1)(C) 2447(a)(1)(D) 2447(a)(2) |
EMEA (35)
APAC (19)
| Framework | Mapping Values |
|---|---|
| APAC Australia Privacy Act | APP Part 8 APP Part 11 |
| APAC Australia ISM June 2024 | ISM-1739 ISM-1743 |
| APAC Australia IoT Code of Practice | Principle 4 Principle 5 Principle 6 Principle 7 |
| APAC Australia Prudential Standard CPS234 | 15 18 |
| APAC China DNSIP | 4 |
| APAC Hong Kong | Principle 4 Sec 33 |
| APAC India ITR | 7 8 |
| APAC India SEBI CSCRF | PR.IP.S17 |
| APAC Japan APPI | 20 |
| APAC Japan ISMAP | 14.1.2 14.2.5 |
| APAC Malaysia | 9 |
| APAC New Zealand HISF 2022 | HHSP16 HML16 HSUP14 |
| APAC New Zealand HISF Suppliers 2023 | HSUP14 |
| APAC New Zealand NZISM 3.6 | 1.2.13.C.01 1.2.13.C.02 |
| APAC Philippines | 25 29 |
| APAC Singapore | 24 26 |
| APAC Singapore MAS TRM 2021 | 5.6.1 5.6.2 5.6.3 11.2.8 |
| APAC South Korea | 3 29 |
| APAC Taiwan | 21 |
Americas (13)
| Framework | Mapping Values |
|---|---|
| Americas Argentina PPL | 9 12 |
| Americas Bahamas | 6 12 |
| Americas Bermuda BMACCC | 4 |
| Americas Brazil LGPD | 6.7 46 37 49 |
| Americas Canada OSFI B-13 | 1.3.1 2 2.1 2.1.2 3.2 3.2.1 |
| Americas Canada ITSP-10-171 | 03.01.12.A 03.01.16.A 03.01.16.B 03.01.16.C 03.01.18.A 03.13.01.C 03.16.01 |
| Americas Canada PIPEDA | Principle 7 |
| Americas Chile | 7 |
| Americas Colombia | 4 26 |
| Americas Costa Rica | 10 14 |
| Americas Mexico | 19 36 37 |
| Americas Peru | 9 11 15 16 17 |
| Americas Uruguay | 5 10 |
Capability Maturity Model
Level 0 — Not Performed
There is no evidence of a capability to facilitate the implementation of industry-recognized cybersecurity and data protection practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).
Level 1 — Performed Informally
Secure Engineering & Architecture (SEA) efforts are ad hoc and inconsistent. CMM Level 1 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- IT personnel use an informal process to design, build and maintain secure solutions.
- IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.
- Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).
Level 2 — Planned & Tracked
Secure Engineering & Architecture (SEA) efforts are requirements-driven and governed at a local/regional level, but are not consistent across the organization. CMM Level 2 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- Architecture/engineering management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
- A Change Advisory Board (CAB), or similar function, exists to govern changes to systems, applications and services, ensuring their stability, reliability and predictability.
- Administrative processes and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
- IT/cybersecurity personnel identify cybersecurity and data protection controls to address applicable statutory, regulatory and contractual requirements for architecture/engineering management.
- IT personnel implement secure engineering practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets, data and network(s).
- Technologies are configured to protect data with the strength and integrity commensurate with the classification or sensitivity of the information and mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides), including cryptographic protections for sensitive/regulated data.
Level 3 — Well Defined
Secure Engineering & Architecture (SEA) efforts are standardized across the organization and centrally managed, where technically feasible, to ensure consistency. CMM Level 3 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- The Chief Information Security Officer (CISO), or similar function with technical competence to address cybersecurity concerns, analyzes the organization's business strategy to determine prioritized and authoritative guidance for secure engineering practices.
- The CISO, or similar function, develops a security-focused Concept of Operations (CONOPS) that documents management, operational and technical measures to apply defense-in-depth techniques across the enterprise for secure engineering.
- A Governance, Risk & Compliance (GRC) function, or similar function, provides governance oversight for the implementation of applicable statutory, regulatory and contractual cybersecurity and data protection controls to protect the confidentiality, integrity, availability and safety of the organization's applications, systems, services and data with regards to secure engineering.
- A steering committee is formally established to provide executive oversight of the cybersecurity and data protection program, including secure engineering.
- IT/cybersecurity architects, or a similar function, enable the implementation a “layered defense” network architecture that enables a resilient defense-in-depth approach through the use of industry-recognized cybersecurity and data protection practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS) (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).
- IT/cybersecurity engineers, or a similar function, operationalize enterprise architecture, aligned with industry-recognized leading practices, with consideration for cybersecurity and data protection principles, including resiliency expectations, that addresses risk to organizational operations, assets, individuals, other organizations.
- A Validated Architecture Design Review (VADR), or similar process, is used to evaluate design criteria for secure practices and conformance with requirements for applicable statutory, regulatory and contractual controls to determine if the system/application/service is designed, built and operated in a secure and resilient manner.
- A Change Advisory Board (CAB), or similar function, governs changes to systems, applications and services to ensure their stability, reliability and predictability.
- A formal Change Management (CM) program helps to ensure that no unauthorized changes are made, all changes are documented, services are not disrupted and resources are used efficiently.
- An Identity & Access Management (IAM) function, or similar function, enables the implementation of identification and access management controls for “least privileges” practices, allowing for the management of user, group and system accounts, including privileged accounts.
- An IT Asset Management (ITAM) function, or similar function, categorizes assets according to the data the asset stores, transmits and/ or processes and applies the appropriate technology controls to protect the asset and data.
Level 4 — Quantitatively Controlled
Secure Engineering & Architecture (SEA) efforts are metrics driven and provide sufficient management insight (based on a quantitative understanding of process capabilities) to predict optimal performance, ensure continued operations and identify areas for improvement. In addition to CMM Level 3 criteria, CMM Level 4 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
- Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
- Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
- Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
- Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
- Both business and technical stakeholders are involved in reviewing and approving proposed changes.
Level 5 — Continuously Improving
See C|P-CMM4. There are no defined C|P-CMM5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to facilitate the implementation of industry-recognized cybersecurity and data protection practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).
Assessment Objectives
- SEA-01_A01 secure engineering principles are defined.
- SEA-01_A02 data privacy engineering principles are defined.
- SEA-01_A03 architectural designs that promote effective cybersecurity / data privacy are identified.
- SEA-01_A04 systems engineering principles that promote effective cybersecurity / data privacy are identified.
- SEA-01_A05 identified architectural designs that promote effective cybersecurity / data privacy are employed.
- SEA-01_A06 identified systems engineering principles that promote effective cybersecurity / data privacy are employed.
- SEA-01_A07 systems security engineering principles to be applied to the development or modification of the system and system components are defined.
- SEA-01_A08 systems security engineering principles are applied in the specification of the system and system components.
- SEA-01_A09 cybersecurity / data privacy engineering principles are applied in the design of the system and system components.
- SEA-01_A10 cybersecurity / data privacy engineering principles are applied in the development of the system and system components.
- SEA-01_A11 cybersecurity / data privacy engineering principles are applied in the implementation of the system and system components.
- SEA-01_A12 cybersecurity / data privacy engineering principles are applied in the modification of the system and system components.
- SEA-01_A13 thresholds to which attack surfaces are to be reduced are defined.
- SEA-01_A14 the developer of the system, system component, or system service is required to reduce attack surfaces to organization-defined thresholds.
- SEA-01_A15 systems are prevented from entering unsecure states in the event of an operational failure of a boundary protection device.
- SEA-01_A16 Secure Engineering & Architecture (SEA) operations are conducted according to documented policies, standards, procedures and/or other organizational directives.
- SEA-01_A17 adequate resources (e.g., people, processes, technologies, data and/or facilities) are provided to support Secure Engineering & Architecture (SEA) operations.
- SEA-01_A18 responsibility and authority for the performance of Secure Engineering & Architecture (SEA)-related activities are assigned to designated personnel.
- SEA-01_A19 personnel performing Secure Engineering & Architecture (SEA)-related activities have the skills and knowledge needed to perform their assigned duties.
Evidence Requirements
- E-TDA-01 Secure Software Development Principles (SSDP)
-
Documented evidence of a Secure Software Development Principles (SSDP). This is program-level documentation in the form of a runbook, playbook or a similar format provides guidance on organizational practices that support existing policies and standards.
Technology Design & Acquisition - E-TDA-02 Secure Engineering & Data Privacy (SEDP)
-
Documented evidence of a Secure Engineering & Data Privacy (SEDP) program. This is program-level documentation in the form of a runbook, playbook or a similar format provides guidance on organizational practices that support existing policies and standards.
Technology Design & Acquisition - E-TDA-04 Design and Development Plan (DDP)
-
Documented evidence of an engineering method to control the design process and govern the lifecycle of the product/service.
Technology Design & Acquisition - E-TDA-08 Secure Engineering Principles (SEP)
-
Documented evidence of defined secure engineering principles used to ensure Sensitivity, Integrity, Availability & Safety (CIAS) concerns are properly addressed in the design and implementation of systems, applications and services.
Technology Design & Acquisition - E-TDA-09 Security Architecture View
-
Documented evidence that identifies security-relevant system elements and their interfaces: • Define security context, domains, boundaries, and external interfaces of the system; • Align the architecture with (a) the system security objectives and requirements, (b) security design characteristics; and • Establish traceability of architecture elements to user and system security requirements.
Technology Design & Acquisition
Technology Recommendations
Micro/Small
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
Small
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
Medium
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
Large
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
Enterprise
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)