| πΌ 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 | 5 | 5 | | no data |
| γπΌ 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); | | | | | no data |
| γπΌ 47b approval of changes prior to deployment into the production environment; | | | | | no data |
| γπΌ 47c segregation of duty controls which prevent personnel from deploying their own software changes to production; | | 5 | 5 | | no data |
| γπΌ 47d changes are developed and verified in another environment, sufficiently segregated from production so as to avoid any compromise of information security; | | | | | no data |
| γπΌ 47e information security requirements are validated prior to deployment; | | | | | no data |
| γπΌ 47f desensitising sensitive production data when used for development or testing purposes; | | | | | no data |
| γπΌ 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. | | | | | no data |