The Pen Test Found It in 2020. The Regulator Found It in 2026.

On 10 August 2026 APRA commenced civil penalty proceedings in the Federal Court against Bendigo and Adelaide Bank. The parties have jointly proposed a penalty of $8 million, and the bank has admitted breaching its obligations under the Banking Executive Accountability Regime in relation to a cyber attack on its Alliance Bank business in March 2023.

Read the admissions rather than the headline, because the interesting part is what the bank is being penalised for.

Between 3 and 7 March 2023 an unidentified attacker reached approximately 257 customer accounts and made 286 unauthorised transactions totalling about $490,000, affecting 87 customers. About $140,000 was not recovered. Every affected customer was reimbursed.

By the standards of Australian breaches that is a small event. The controls have since been remediated, and APRA says plainly that it does not currently have concerns about the bank’s information security controls.

APRA went to court anyway.

The weaknesses were found six years ago by a test that worked

APRA describes significant weaknesses in customer authentication for online banking: password settings that permitted very weak passwords, multiple customer accounts with identical passwords, and system design features that let an attacker identify valid customer IDs.

Then the sentence that makes this worth twenty minutes of your time:

A number of those weaknesses were identified by penetration testing conducted in 2020 but were not addressed by Bendigo Bank prior to the cyber attack.

The test was not the failure. The test was the one thing that worked. It went looking for weaknesses and it found them, three years before anyone exploited them.

What failed was everything that was supposed to happen next.

Only one of the four admissions is about the controls

The bank admitted failing to do four things. It is worth listing them as APRA did, because the shape of the list is the story.

• Maintain adequate customer authentication controls to prevent and detect unauthorised access
• Undertake a systematic testing program for those controls, as required by Prudential Standard CPS 234 Information Security
• Have adequate governance and risk management for the information security of the IT system that gave customers digital access
• Ensure the responsibilities of accountable persons appropriately covered that IT system

One admission is about the control itself. The other three are about testing, governance and accountability. That is a management system failure described in regulatory language, and if you strip the banking vocabulary out it maps almost line for line onto the parts of ISO 27001 that organisations most often treat as paperwork.

Testing is an obligation that does not depend on the outcome

This is the part worth taking away even if you will never be APRA-regulated.

The financial impact was limited. The customers were made whole. The weaknesses were fixed. The regulator still asked a court to impose an eight million dollar penalty, and its Deputy Chair, Therese McCarthy Hockey, explained why in one sentence:

While the financial impact of this cyber incident was limited, our court action sends a clear message that all APRA-regulated entities must have appropriate cyber protection systems and regularly test the adequacy of those controls.

Regularly test the adequacy of those controls. Not “have controls”. Not “avoid losses”.

That is the argument for clause 9.1, monitoring, measurement, analysis and evaluation, and for clause 9.2 internal audit, stated by a regulator rather than an auditor. Both clauses exist to produce evidence that your controls work, on a schedule, whether or not anything has gone wrong. Organisations routinely treat them as the annual chore that proves nothing happened. This case is what it looks like when a regulator treats the absence of that evidence as the offence.

Note the word “program” in the admission too. Not a test. A programme: scheduled, scoped, repeated, and covering the controls that actually matter. One test in 2020 was not a programme, and the gap between those two things is exactly what an audit programme under 9.2 is meant to close.

A penetration test is a finding, not a control

Here is the failure mode that will be familiar to anyone who has run a management system.

A test produces findings. The findings go into a report. The report goes to someone. And then the loop either closes or it does not, and nothing in the organisation is designed to notice the difference.

In ISO 27001 terms the missing piece is clause 10.2, nonconformity and corrective action: react to the nonconformity, deal with the consequences, work out why it happened, act to stop it recurring, and then review the effectiveness of what you did. That last step is the one that gets skipped, and it is the only step that would have caught this. Closing a finding is not the same as verifying it stayed closed.

The uncomfortable corollary: an open finding you have documented is worse than one you never looked for. You have created a written record that you knew. That is what turns a control weakness into an accountability failure, and it is why a findings register with no verified closure is a liability rather than evidence.

If you hold ISO 27001, go and look at your own register today. Not the count of open items, the age of them. Anything sitting there since a test two years ago is this case.

The password detail is the one an internal audit would have caught

Strip the sophistication out of this and look at what was actually wrong. Password settings that allowed very weak passwords. Multiple customer accounts with identical passwords. A system that let an attacker work out which customer IDs were real.

None of that requires a specialist to find. Annex A 5.17, authentication information covers exactly this ground, and a sampling exercise against your own password policy is an afternoon’s work for an internal auditor. Pull the configured settings, compare them to the policy, sample the results, and report the difference.

The identical-passwords finding in particular is the kind of thing that only survives when nobody has ever looked. It is not a gap in knowledge. It is a gap in checking.

The accountability gap, which is the same failure as an unscoped subsidiary

The fourth admission is that the responsibilities of accountable persons did not appropriately cover the Alliance Bank IT system. The system existed. People used it. It just was not clearly anybody’s responsibility.

That is clause 5.3, roles, responsibilities and authorities, and it is the same failure mode as a subsidiary, a legacy platform or an acquired business sitting outside a certified ISMS scope. The org chart and the asset inventory disagree, and the gap between them is where nothing gets tested because nobody owns it.

Worth asking directly at your next management review: is there a system in this business that would not appear on anyone’s list if we asked each manager to name what they are responsible for?

What to check

Four questions, not a project.

Find your last test report and follow the findings. Penetration test, vulnerability scan, internal audit, external audit, it does not matter which. For each finding, can you show what was done, when, and the evidence that it was verified as effective? If the answer is a closed status with no verification, the loop is open.

Ask whether you have a testing programme or just tests. A programme names which controls get tested, how often, by whom, and to what depth, and it is approved and reviewed. If your testing is whatever the budget allowed last year, that is not a programme.

Sample your authentication settings against your own policy this week. Configured minimum length, complexity, reuse, lockout, MFA coverage. Compare them to what your policy says. Do not accept the policy as evidence of the setting.

Reconcile your asset inventory to your org chart. Every system that holds or moves information should have a named owner who knows they own it. The ones that fail this test are the ones that never get tested.

Where this fits

Everything above sits inside an ISO 27001 information security management system: 5.3 for accountability, Annex A 5.17 for authentication, 9.1 and 9.2 for testing and audit, and 10.2 for closing what those find.

We have written before about how closely a cyber insurer’s questions track an ISO 27001 auditor’s, and about the logins nobody turned off, which is the same class of control failure found by the same class of routine check.

The pattern in this case is not a banking pattern. An organisation ran a test, the test worked, the findings were real, and the organisation did not close them. Three years later somebody used them. Three years after that a regulator asked a court for eight million dollars, not because of the loss, but because of the gap between finding a weakness and fixing it.

A finding you have not closed is not evidence that your system is working. It is evidence that you knew.

Sources

• APRA, Bendigo and Adelaide Bank admits to breaching its BEAR obligations in relation to cyber incident, 11 August 2026
• APRA, Originating Application and Statement of Agreed Facts and Admissions, August 2026 (attachments to the media release above)

The proceedings described are before the Federal Court. The penalty is proposed by the parties, not imposed, and it is a matter for the Court to determine whether the declarations and the penalty are appropriate.