Back

Perform Quality Management on all newly developed or modified software.


CONTROL ID
11798
CONTROL TYPE
Testing
CLASSIFICATION
Detective

SUPPORTING AND SUPPORTED CONTROLS




This Control directly supports the implied Control(s):
  • Initiate the System Development Life Cycle development phase or System Development Life Cycle build phase., CC ID: 06267

This Control has the following implementation support Control(s):
  • Establish, implement, and maintain a system testing program for all system development projects., CC ID: 01101


SELECTED AUTHORITY DOCUMENTS COMPLIED WITH




  • App 2-1 Item Number III.5(1): The person in charge of software development and the test leader must approve the system test plan. This is a control item that constitutes a greater risk to financial information. This is an IT general control. App 2-1 Item Number III.5(2): The persons in charge of the… (App 2-1 Item Number III.5(1), App 2-1 Item Number III.5(2), App 2-1 Item Number V.4(1) thru App 2-1 Item Number V.4(4), Appendix 1 Correspondence of the System Management Standards - Supplementary Edition to other standards)
  • An application security review/testing, initially and during major changes, needs to be conducted using a combination of source code review, stress loading, exception testing and compliance review to identify insecure coding techniques and systems vulnerabilities to a reasonable extent. (Critical components of information security 11) c.30., Guidelines on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds)
  • It is important that the FI assesses the robustness of the vendor's software development and quality assurance practices, and ensures stringent security practices are in place to safeguard and protect any sensitive data the vendor has access to over the course of the project. Any vendor access to th… (§ 5.3.2, Technology Risk Management Guidelines, January 2021)
  • The organization should assess if the information technology security requirements are met when reviewing and testing software that is being developed. (Attach D ¶ 2(c)(i), APRA Prudential Practice Guide 234: Management of security risk in information and information technology)
  • The organization should determine if the software works as intended when reviewing and testing newly developed software. (Attach D ¶ 2(c)(ii), APRA Prudential Practice Guide 234: Management of security risk in information and information technology)
  • The organization should test the expected behavior when erroneous support is supplied when testing and reviewing newly developed software. (Attach D ¶ 2(c)(iii), APRA Prudential Practice Guide 234: Management of security risk in information and information technology)
  • continues to function as intended regardless of unforeseen circumstances, including where erroneous input is supplied; (49(a)., APRA Prudential Practice Guide CPG 234 Information Security, June 2019)
  • whether the software works as intended; and (Attachment D ¶ 2(c)(ii), The AD_offical_Name should be: APRA Prudential Practice Guide 234: Management of security risk in information and information technology, May 2013)
  • security reviews. Software reviews, tools and testing are normally used to identify vulnerabilities prior to implementation. Several assessments throughout the software life-cycle may also be appropriate. The level and type of review would normally be commensurate with the level of risk, sensitivity… (Attachment D ¶ 2(c), The AD_offical_Name should be: APRA Prudential Practice Guide 234: Management of security risk in information and information technology, May 2013)
  • Appropriate processes shall be defined for application development which contain specifications for identifying requirements, for the development objective, for (technical) implementation (including coding guidelines), for quality assurance, and for testing, approval and release. (II.6.36, Circular 10/2017 (BA): Supervisory Requirements for IT in Financial Institutions, 14.09.2018)
  • Hardware and software should be developed and tested under a Quality Assurance system. (¶ 13.1, Good Practices For Computerized systems In Regulated GXP Environments)
  • All reasonable steps should be taken to ensure software is produced in accordance with a system of Quality Assurance. (¶ 5, PE 009-8, Guide to Good Manufacturing Practice for Medicinal Products, Annex 11, 15 January 2009)
  • Develop, resource and execute a software QA plan to obtain the quality specified in the requirements definition and the organisation's quality policies and procedures. (AI2.8 Software Quality Assurance, CobiT, Version 4.1)
  • Adopt and maintain standards for all development and acquisition that follow the life cycle of the ultimate deliverable, and include sign-off at key milestones based on agreed-upon sign-off criteria. Consider software coding standards; naming conventions; file formats; schema and data dictionary des… (PO8.3 Development and Acquisition Standards, CobiT, Version 4.1)
  • The testing and validation of developed software is outsourced by many organizations. Specialized testing is required to monitor system performance and identify and correct programming problems and errors. Internal auditors should review the following during the testing and validation phase: if the … (§ 3 (Independent Testing and Validation), IIA Global Technology Audit Guide (GTAG) 7: Information Technology Outsourcing)
  • Critical desktop applications should be tested to ensure that they function as required. (CF.13.04.08a, The Standard of Good Practice for Information Security)
  • Critical desktop applications should be tested to ensure that they meet security requirements. (CF.13.04.08b, The Standard of Good Practice for Information Security)
  • Critical desktop applications should be tested to ensure that they function as required. (CF.13.04.08a, The Standard of Good Practice for Information Security, 2013)
  • Critical desktop applications should be tested to ensure that they meet security requirements. (CF.13.04.08b, The Standard of Good Practice for Information Security, 2013)
  • A program for the systematic monitoring and evaluation to ensure that standards of quality and security baselines are being met shall be established for all software developed by the organization. Quality evaluation and acceptance criteria for information systems, upgrades, and new versions shall be… (CCC-03, Cloud Controls Matrix, v3.0)
  • Follow a defined quality change control, approval and testing process with established baselines, testing, and release standards. (CCC-02, Cloud Controls Matrix, v4.0)
  • Data input and output integrity routines (i.e., reconciliation and edit checks) shall be implemented for application interfaces and databases to prevent manual or systematic processing errors or corruption of data. (SA-05, The Cloud Security Alliance Controls Matrix, Version 1.3)
  • Establish a process to accept and address reports of software vulnerabilities, including providing a means for external entities to contact your security group. (CIS Control 18: Sub-Control 18.8 Establish a Process to Accept and Address Reports of Software Vulnerabilities, CIS Controls, 7.1)
  • Establish a process to accept and address reports of software vulnerabilities, including providing a means for external entities to contact your security group. (CIS Control 18: Sub-Control 18.8 Establish a Process to Accept and Address Reports of Software Vulnerabilities, CIS Controls, V7)
  • The organization shall create software elements and compile, inspect, and test them to verify they conform to the design criteria. (§ 6.4.4.3(b)(1)(ii), ISO 15288-2008 Systems and software engineering - System life cycle processes, R 2008)
  • Evaluation can lead to better security results. The evaluation will identify errors or vulnerabilities that the developer can correct, possibly preventing security failures in the future. The developer may take more care in the design and development process if he/she knows that the software will be… (§ 6.2.2, ISO 15408-1 Common Criteria for Information Technology Security Evaluation Part 1, 2005)
  • § 5.6.3: For software systems assigned to Class B and Class C software safety classes, the medical device manufacturer shall use the integration test plan to test the integrated software items and document the test results. § 5.7.1: For software systems assigned to Class B and Class C software saf… (§ 5.6.3, § 5.7.1, ISO 62304 - 2006 Medical device software - Software life cycle processes, 2006)
  • When application development is performed, is Internet facing software and infrastructure tested prior to implementation? (§ I.2.21, Shared Assessments Standardized Information Gathering Questionnaire - I. Information Systems Acquisition Development & Maintenance, 7.0)
  • Does the formal software development life cycle process include integration testing? (§ I.2.7.1, Shared Assessments Standardized Information Gathering Questionnaire - I. Information Systems Acquisition Development & Maintenance, 7.0)
  • Patches, upgrades, and new applications must be tested before being deployed. (DCCT-1, DoD Instruction 8500.2 Information Assurance (IA) Implementation)
  • Software development initiatives must specify the software quality requirements and validation methods for minimizing malformed or flawed software. (DCSQ-1, DoD Instruction 8500.2 Information Assurance (IA) Implementation)
  • Any change to a software product that has been baselined should have its own mini-lifecycle, including testing. (§ 5.2.5 ¶ 13, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Version 2.0)
  • Any software modifications due to faults found during user site testing should follow the same procedures and controls as would any other software change. (§ 5.2.6 ¶ 8, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Version 2.0)
  • Device manufacturers should consider how changes may impact the used portions of the software and reconfirm the validation of those parts, whenever software is upgraded or changed. (§ 6.1 ¶ 2, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Version 2.0)
  • The security controls of internally developed software are periodically reviewed and tested. (*N/A if there is no software development.) (Domain 3: Assessment Factor: Preventative Controls, SECURE CODING Baseline 3 ¶ 2, FFIEC Cybersecurity Assessment Tool, Baseline, May 2017)
  • Systems, applications, and data recovery is tested at least annually. (Domain 5: Assessment Factor: Resillience Planning and Strategy, TESTING Baseline 2 ¶ 3, FFIEC Cybersecurity Assessment Tool, Baseline, May 2017)
  • Software is reviewed through both automated software testing and code reviews. (App A Objective 6.19.d, FFIEC Information Technology Examination Handbook - Information Security, September 2016)
  • Performs tests associated with QA and QC independent of the programming function, and whether the QA and QC procedures incorporate user acceptance testing programs. (App A Objective 13:6 c., FFIEC Information Technology Examination Handbook - Management, November 2015)
  • Review authorization and assurance documents to confirm that the level of risk is within acceptable limits for each software application, system, and network. (T0221, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Develop secure software testing and validation procedures. (T0456, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Test and evaluate locally developed tools for operational use. (T0828, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • The security engineering principles must include testing for validating the secure coding effectiveness. (SG.SA-8 Requirement 7, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • Test and evaluate locally developed tools for operational use. (T0828, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Implement new system design procedures, test procedures, and quality standards. (T0121, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Develop secure software testing and validation procedures. (T0456, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Each Covered Entity's cybersecurity program shall include written procedures, guidelines and standards designed to ensure the use of secure development practices for in-house developed applications utilized by the Covered Entity, and procedures for evaluating, assessing or testing the security of ex… (§ 500.08 Application Security (a), New York Codes, Rules and Regulations, Title 23, Chapter 1, Part 500 Cybersecurity Requirements for Financial Services Companies)