Back

Establish, implement, and maintain system design requirements.


CONTROL ID
06618
CONTROL TYPE
Establish/Maintain Documentation
CLASSIFICATION
Preventive

SUPPORTING AND SUPPORTED CONTROLS



This Control directly supports the implied Control(s):
  • Initiate the System Development Life Cycle planning phase., CC ID: 06266

This Control has the following implementation support Control(s):
  • Implement dual authorization in systems with critical business functions, as necessary., CC ID: 14922
  • Identify all stakeholders who may influence the System Development Life Cycle., CC ID: 06922
  • Compare system design requirements against system design requests., CC ID: 06619
  • Design and develop built-in redundancies, as necessary., CC ID: 13064
  • Identify and document system design constraints., CC ID: 06923
  • Identify and document system development constraints., CC ID: 11698
  • Identify and document the system boundaries of the system design project., CC ID: 06924
  • Determine if commercial off the shelf products meet the system design requirements., CC ID: 06926
  • Review the degree of human intervention and control points in the system design requirements., CC ID: 13536
  • Evaluate the criticality and sensitivity of information being accessed when designing systems., CC ID: 07076
  • Include performance criteria in the system requirements specification., CC ID: 11540
  • Include anti-counterfeit measures in the system requirements specification., CC ID: 11547


SELECTED AUTHORITY DOCUMENTS COMPLIED WITH



  • AIs should adopt and implement a full project life cycle methodology governing the process of developing, implementing and maintaining major computer systems. In general, this should involve phases of project initiation, feasibility study, requirement definition, system design, program development, … (4.2.1, Hong Kong Monetary Authority: TM-G-1: General Principles for Technology Risk Management, V.1 – 24.06.03)
  • A bank needs to incorporate information security at all stages of software development. This would assist in improving software quality and minimizing exposure to vulnerabilities. Besides business functionalities, security requirements relating to system access control, authentication, transaction a… (Critical components of information security 11) c.4., Guidelines on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds)
  • Given the critical role of security technologies as part of the information security framework, banks need to subject them to suitable controls across their lifecycle like guidelines on their usage, standards and procedures indicating the detailed objectives and requirements of individual informatio… (Critical components of information security 1) 4), Guidelines on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds)
  • The FI should identify, define and document the functional requirements for the IT system. In addition to functional requirements, key requirements such as system performance, resilience and security controls, should also be established and documented. (§ 5.5.1, Technology Risk Management Guidelines, January 2021)
  • As part of the design phase, the FI should review the proposed architecture and design of the IT system, including the IT controls to be built into the system, to ensure they meet the defined requirements, before implementation. (§ 5.6.1, Technology Risk Management Guidelines, January 2021)
  • Systems and applications are designed, deployed, maintained and decommissioned according to their value and their confidentiality, integrity and availability requirements. (P1:, Australian Government Information Security Manual, March 2021)
  • Systems and applications are designed, deployed, maintained and decommissioned according to their value and their confidentiality, integrity and availability requirements. (P1:, Australian Government Information Security Manual, June 2023)
  • Systems and applications are designed, deployed, maintained and decommissioned according to their value and their confidentiality, integrity and availability requirements. (P1:, Australian Government Information Security Manual, September 2023)
  • A financial institution should ensure that, before any acquisition or development of ICT systems takes place, the functional and non-functional requirements (including information security requirements) are clearly defined and approved by the relevant business management. (3.6.2 68, Final Report EBA Guidelines on ICT and security risk management)
  • if the organization designs information systems for its sustainability reporting, design these systems in a way that they can be examined as part of an external assurance process; (Verifiability Guidance ¶ 2 Bullet 3, GRI 1: Foundation 2021)
  • The organization should establish system control documentation or a system description that gives a detailed system description, covers maintenance and development, and provides a definitive statement on what the system must or must not do. (¶ 9.1, Good Practices For Computerized systems In Regulated GXP Environments)
  • The user requirement specifications should include the functional requirements and the non-functional requirements, such as effectiveness, functionality, usability, and maintainability and they should be objectively verifiable. (¶ 9.3 Bullet 5, Good Practices For Computerized systems In Regulated GXP Environments)
  • Prepare detailed design and technical software application requirements. Define the criteria for acceptance of the requirements. Have the requirements approved to ensure that they correspond to the high-level design. Perform reassessment when significant technical or logical discrepancies occur duri… (AI2.2 Detailed Design, CobiT, Version 4.1)
  • Critical desktop applications standards and procedures should cover specifying requirements. (CF.13.04.01-2, The Standard of Good Practice for Information Security)
  • Business requirements for systems under development should be documented in a specification of business requirements (or equivalent) and supported by an agreed process for handling changes to requirements. (CF.18.01.01, The Standard of Good Practice for Information Security)
  • Before coding or acquisition work begins, system designs should be documented. (CF.18.02.07a, The Standard of Good Practice for Information Security)
  • Critical desktop applications standards and procedures should cover specifying requirements. (CF.13.04.01-2, The Standard of Good Practice for Information Security, 2013)
  • Business requirements for systems under development should be documented in a specification of business requirements (or equivalent) and supported by an agreed process for handling changes to requirements. (CF.18.01.01, The Standard of Good Practice for Information Security, 2013)
  • Before coding or acquisition work begins, system designs should be documented. (CF.18.02.07a, The Standard of Good Practice for Information Security, 2013)
  • The organization shall analyze the architectural design to determine the design criteria for each element. (§ 6.4.3.3(b)(1), ISO 15288-2008 Systems and software engineering - System life cycle processes, R 2008)
  • The organization shall identify the system requirements that are allocated to the operators. (§ 6.4.3.3(b)(2), ISO 15288-2008 Systems and software engineering - System life cycle processes, R 2008)
  • The organization shall maintain a mutual traceability between the system requirements and the design requirements. (§ 6.4.3.3(c)(3), ISO 15288-2008 Systems and software engineering - System life cycle processes, R 2008)
  • Strategies for keeping electronic records and its associated metadata that are removed from the system have to be designed and integrated into the system design process so the records and metadata will be accessible and usable for the entire retention period. (§ 4.3.9.2 ¶ 6, ISO 15489-2: 2001, Information and Documentation: Records management: Part 2: Guidelines)
  • The design and development planning should end with a plan that identifies the necessary tasks, the necessary resources, the procedures for anomaly reporting and resolution, and management review requirements. (§ 5.2.1 ¶ 1, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Version 2.0)
  • The design and development plan should include the important quality factors, such as maintainability, usability, and reliability. (§ 5.2.1 ¶ 1 Bullet 2, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Version 2.0)
  • The design and development plan should include the task acceptance criteria. (§ 5.2.1 ¶ 1 Bullet 4, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Version 2.0)
  • The design and development plan should include the inputs for each task. (§ 5.2.1 ¶ 1 Bullet 6, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Version 2.0)
  • The design and development plan should include the outputs of each task. (§ 5.2.1 ¶ 1 Bullet 7, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Version 2.0)
  • Develops design requirements and parameters for analytics. (App A Objective 3:9d, FFIEC Information Technology Examination Handbook - Architecture, Infrastructure, and Operations, June 2021)
  • Evaluates its needs and considers: (App A Objective 12:4b, FFIEC Information Technology Examination Handbook - Architecture, Infrastructure, and Operations, June 2021)
  • Flexibility. (App A Objective 12:4c Bullet 5, FFIEC Information Technology Examination Handbook - Architecture, Infrastructure, and Operations, June 2021)
  • Interoperability and integration. (App A Objective 12:4c Bullet 7, FFIEC Information Technology Examination Handbook - Architecture, Infrastructure, and Operations, June 2021)
  • Development of appropriate design objectives, including changes, EOL, and identification of shadow IT. (IV Action Summary ¶ 2 Bullet 4, FFIEC Information Technology Examination Handbook - Architecture, Infrastructure, and Operations, June 2021)
  • System requirements (e.g., "the system shall respect the privacy of its users") are elicited from and understood by relevant AI actors. Design decisions take socio-technical implications into account to address AI risks. (MAP 1.6, Artificial Intelligence Risk Management Framework, NIST AI 100-1)
  • Scientific integrity and TEVV considerations are identified and documented, including those related to experimental design, data collection and selection (e.g., availability, representativeness, suitability), system trustworthiness, and construct validation. (MAP 2.3, Artificial Intelligence Risk Management Framework, NIST AI 100-1)
  • Develop and document requirements, capabilities, and constraints for design procedures and processes. (T0062, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Analyze security needs and software requirements to determine feasibility of design within time and cost constraints and security mandates. (T0428, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Develop and document requirements, capabilities, and constraints for design procedures and processes. (T0062, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Analyze security needs and software requirements to determine feasibility of design within time and cost constraints and security mandates. (T0428, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)