| 💼 47 APRA envisages that a regulated entity would implement controls to manage changes to information assets, including changes to hardware, software, data, and configuration (both where the change is planned and in response to an emergency) with the aim of maintaining information security. | 7 | | | |
| 💼 47a security testing (including reviews) to identify vulnerabilities and confirm information security requirements have been met. The nature of testing would be commensurate with the scope of the change and the sensitivity and criticality of the impacted information asset (refer to Attachment H for examples of common testing techniques); | | | | |
| 💼 47b approval of changes prior to deployment into the production environment; | | | | |
| 💼 47c segregation of duty controls which prevent personnel from deploying their own software changes to production; | | 5 | 5 | |
| 💼 47d changes are developed and verified in another environment, sufficiently segregated from production so as to avoid any compromise of information security; | | | | |
| 💼 47e information security requirements are validated prior to deployment; | | | | |
| 💼 47f desensitising sensitive production data when used for development or testing purposes; | | | | |
| 💼 47g intentionally introduced information security vulnerabilities are authorised. In APRA’s view, changes that knowingly introduce security vulnerabilities would be minimised and, where possible, compensating controls implemented. This situation normally arises when dealing with system outages. | | | | |