## Control 8.25: The development proces

Control 8.25, "Secure development life cycle," is the most overarching, establishing rules for integrating information security across the entire software and system development process [Source 1, 88]. Its focal point is on defining security within methodologies, setting checkpoints, and managing source code and configurations throughout the development lifecycle [Source 1, 88]. This control would be applied from the very beginning of the development process, laying the groundwork for how security is handled across all phases, including planning, design, implementation, and testing.
## Controls 8.26 – 8.28: Specification, Design and Coding

Control 8.27, "Secure system architecture and engineering principles," centers on the foundational design and engineering principles for building secure systems [Source 1, 89]. Its purpose is to ensure that security is embedded from the ground up, incorporating concepts like "security by design" and "defence in depth" across all architectural layers [Source 1, 89]. This control is primarily applied during the **early architectural and design phases** of a software system.

Control 8.26, "Application security requirements," concentrates on identifying, specifying, and approving all necessary information security requirements for applications during their development or acquisition [Source 1, 88]. This involves a high-level definition of security objectives and constraints, often derived from risk assessments, business needs, legal, statutory, regulatory, and contractual requirements [Source 1, 88, 112]. It covers aspects like access control, data protection, and resilience against attacks [Source 1, 88]. This control is crucial during the **requirements and design phases**, defining *what* security an application needs to achieve.

Finally, Control 8.28, "Secure coding," specifically addresses the **practical application of secure programming techniques during the actual writing of software code** to minimize vulnerabilities [Source 1, 89]. Its focal point is on the technical methods and practices employed by developers, including adhering to secure coding principles, using secure development tools, and employing techniques like peer review and static analysis to ensure the software is built securely [Source 1, 89]. This control is directly implemented during the **coding and development** phases, focusing on *how* to technically implement the security defined by controls like 8.26.

In essence, controls 8.26 and 8.27 provide the "**what**" and "**why**" of security (requirements and foundational principles) during earlier phases, while 8.28 focuses on the "**how**" (technical implementation in code) during later, hands-on development phases.
## Controls 8.29, 8.31, and 8.33: Testing

**Control 8.29, "Security testing in development and acceptance,"** focuses on **validating that information security requirements are met** when applications or code are deployed to the production environment . Its primary purpose is to ensure that new information systems, upgrades, and new versions are **thoroughly tested and verified for security during the development processes** . This control is a crucial part of the development lifecycle, specifically applied during the **testing and acceptance phases** before deployment to a live environment.

• **Control 8.31, "Separation of development, test and production environments,"** is foundational, establishing rules for **maintaining distinct and secure environments** for different stages of the system lifecycle [1, 2]. Its focal point is to prevent the compromise of live production data and systems by activities occurring in development or testing [2-4]. This control mandates measures like physical or virtual separation, strict authorization for software deployment, and prohibiting development tools from production systems [5, 6]. It is applied throughout the **setup and ongoing management of system environments**, ensuring that the integrity and confidentiality of production remain uncompromised during development and testing efforts [2, 5].

• **Control 8.33, "Test information,"** specifically addresses the **selection, protection, and management of data used in testing** [1, 10]. Its primary purpose is to **ensure the relevance and integrity of testing while rigorously protecting sensitive operational information** from exposure or misuse [10]. This control emphasizes strict measures, such as avoiding the direct copying of sensitive production data into development and testing environments, or requiring masking techniques if such data must be used [11]. It also mandates that test environments employ access controls comparable to production, that copying of operational information is authorized and logged, and that test data is securely deleted after use [12]. This control is directly applied during the **testing phase** of software and system development [11].

## Controls 8.32: Change management
• **Control 8.32, "Change management,"** centers on the structured **control of all modifications to information processing facilities and information systems** [1, 7]. Its purpose is to **preserve information security** when changes are introduced, preventing unintended impacts on the confidentiality, integrity, and availability of information [7, 8]. This involves defining a formal process that includes planning, impact assessment, authorization, comprehensive testing, communication to relevant parties, and maintaining detailed records of all changes [9]. This control is crucial across the **entire system development lifecycle, including operational and maintenance phases**, ensuring that security is upheld with every alteration [8].


In essence, while controls like 8.25 through 8.28 define _how secure software is built_, controls 8.31 through 8.33 provide the framework for _securely managing and deploying_ that software, focusing on the environments, processes, and data that surround the application as it moves from development to operation.