APRA CPS 234

APRA must be notified as soon as possible and no later than 72 hours after the entity becomes aware of an incident that materially affected or could have materially affected the entity or its customers, or that has been notified to another regulator in any jurisdiction.

• Notification records with awareness and submission timestamps
• Materiality assessment criteria and decision records
• Register of notifications made to other regulators

• Clock started at incident confirmation rather than awareness
• Incidents notified to other regulators not passed to APRA

APRA must be notified as soon as possible and no later than 10 business days after the entity becomes aware of a material information security control weakness it expects it will not be able to remediate in a timely way.

• Notification records with awareness dates
• Weakness register with materiality and remediation feasibility assessments
• Evidence linking testing and audit findings to notification decisions

• No process connecting the weakness register to the notification duty
• Materiality threshold undocumented

Controls protecting information assets must be implemented in a timely way and sized to the vulnerabilities and threats, the criticality and sensitivity of the assets, the asset life cycle stage and the potential consequences of an incident.

• Control set mapped to classified assets
• Evidence of timeliness of control implementation
• Life cycle coverage from design through to disposal

• Controls applied uniformly with no reference to classification
• Decommissioning and disposal stages uncontrolled

The entity must have robust mechanisms to detect information security incidents and respond to them in a timely way.

• Detection tooling and monitoring coverage evidence
• Incident records showing detection and response times
• Defined response timeliness expectations

• Detection coverage gaps across classified assets
• No measurement of detection or response timeliness

Information security response plans must be reviewed and tested annually to confirm they remain effective and fit for purpose.

• Annual review and test records for response plans
• Exercise reports and resulting plan updates
• Evidence of fitness for purpose conclusions

• Plans reviewed but never exercised
• Test findings not fed back into the plans

The entity must maintain response plans covering the information security incidents it considers could plausibly occur.

• Documented response plans
• Plausible incident scenario analysis supporting plan coverage
• Version and approval history

• Single generic plan with no scenario basis
• Plausible scenarios identified but not planned for

Response plans must set out the mechanisms for managing every stage of an incident from detection through to post incident review, and for escalating and reporting incidents to the Board and to those responsible for incident management and oversight.

• Plan sections covering each incident stage
• Escalation matrix with thresholds and recipients
• Post incident review records

• Plans stop at containment with no post incident review
• Escalation path to the Board undefined

Information assets, including those held by related parties and third parties, must be classified by criticality and sensitivity reflecting the potential impact of an incident on the entity or on depositors, policyholders, beneficiaries and other customers.

• Information asset register with criticality and sensitivity ratings
• Classification scheme and rating rationale
• Coverage evidence for third party held assets

• Register covers internally hosted assets only
• Classification not tied to impact on customers or the entity

The entity must maintain an information security capability sized to the threats facing its information assets and sufficient to keep the entity operating soundly.

• Capability assessment covering resources, skills and controls
• Resourcing and budget records for the security function
• Skills matrix for security personnel

• Capability asserted but never assessed
• No link between assessed threat level and resourcing

The entity must actively maintain its information security capability as vulnerabilities and threats change, including changes driven by its information assets or business environment.

• Threat and vulnerability monitoring inputs
• Records of capability adjustments following change
• Change triggers linking asset or environment change to capability review

• Capability set once at implementation and not revisited
• No trigger connecting business change to capability review

Internal audit activities must include review of the design and operating effectiveness of information security controls, including those maintained by related parties and third parties.

• Internal audit plan covering information security
• Audit reports on control design and operating effectiveness
• Scope evidence covering third party maintained controls

• Audit covers design only and not operating effectiveness
• Third party controls out of audit scope

Internal audit must assess the control assurance provided by a related party or third party where an incident affecting the assets could materially affect the entity or its customers and internal audit intends to rely on that assurance.

• Reliance decisions recorded with supporting assessment
• Assessment of the third party assurance reports relied upon
• Materiality determination for each reliance

• Third party assurance accepted without assessment
• No record of why reliance was considered appropriate

The entity must ensure that information security control assurance is provided by personnel who are appropriately skilled in providing that assurance.

• Qualifications and experience records for assurance providers
• Training and competency evidence
• Co sourcing or specialist engagement records where in house skill is absent

• General auditors assuring specialist security controls
• Competency assumed and never evidenced

The entity must maintain an information security policy framework proportionate to its exposure to vulnerabilities and threats.

• Approved policy, standard, guideline and procedure set
• Approval and version history
• Mapping of policy coverage to assessed exposures

• Policy set not refreshed against changing exposures
• Standards and procedures missing beneath the top level policy

The information security policy framework must give direction on the responsibilities of every party obliged to maintain information security, including staff, contractors, consultants, related parties, third parties and customers.

• Policy clauses addressed to each party type
• Acknowledgement records for staff and contractors
• Contractual or terms of use flow down to third parties and customers

• Policy addressed to employees only
• No evidence the policy reached third parties or customers

The Board carries ultimate responsibility for the entity information security and must ensure it is maintained in proportion to the threats facing the information assets.

• Board charter or terms of reference assigning information security responsibility
• Board minutes evidencing oversight of information security
• Board reporting pack on the threat environment

• Responsibility delegated to management with no Board level accountability
• No Board record of considering the threat environment

Information security roles and responsibilities must be clearly defined for the Board, senior management, governing bodies and individuals holding decision making, approval, oversight or operational duties.

• Documented roles and responsibilities matrix
• Committee and working group terms of reference
• Position descriptions naming information security duties

• Roles defined for IT only and not for the Board or governing bodies
• Matrix exists but is not approved or maintained

Control effectiveness must be tested through a systematic program whose nature and frequency reflect the rate of change in vulnerabilities and threats, asset criticality and sensitivity, incident consequences, exposure to environments where the entity cannot enforce its policies, and the materiality and frequency of change to information assets.

• Documented testing program and schedule
• Test results and coverage records
• Rationale linking test frequency to the five listed factors

• Ad hoc testing with no program
• Untrusted environments excluded from scope

Testing results that identify control deficiencies which cannot be remediated in a timely way must be escalated and reported to the Board or senior management.

• Escalation records for unremediated deficiencies
• Board or senior management reporting packs
• Remediation tracker with timeliness assessment

• Deficiencies tracked operationally but never escalated
• No definition of what timely remediation means

Testing must be carried out by specialists who are appropriately skilled and functionally independent of the activity being tested.

• Tester qualifications and credentials
• Independence declarations or engagement letters
• Reporting lines demonstrating functional independence

• Controls tested by the team that operates them
• Skill of testers never evidenced

The sufficiency of the testing program must be reviewed at least annually, and also whenever there is a material change to information assets or the business environment.

• Annual sufficiency review records
• Change triggered reviews with the triggering event recorded
• Program amendments arising from review

• Testing performed annually but the program itself never reviewed
• No trigger for review on material change

Where a related party or third party manages information assets, the entity must assess that party information security capability in proportion to the consequences of an incident affecting those assets.

• Third party and related party security capability assessments
• Register of parties managing information assets
• Consequence rating driving assessment depth

• Assessment limited to outsourced material business activities
• Related parties excluded from assessment

Where a related party or third party manages the entity information assets, the entity must evaluate the design of that party controls protecting those assets.

• Design evaluations of third party control sets
• Assurance reports reviewed with entity conclusions recorded
• Scope evidence covering all parties managing information assets

• Reliance on a certificate with no design evaluation
• Evaluation limited to outsourcing arrangements

Where the entity relies on a related party or third party testing of controls over its information assets, it must assess whether the nature and frequency of that testing meets the same factors that govern its own testing program.

• Assessment of third party testing scope and frequency
• Register of testing reliance decisions
• Comparison against the entity own testing factors

• Third party test reports filed without assessment
• No record of which controls the entity relies on the third party to test