Most fintechs aren’t APRA-regulated, so CPS 234 doesn’t bind them directly — it arrives through service-provider clauses in contracts with the banks, insurers and super funds it does bind. ISO 27001 certification is the common way to evidence those CPS 234-shaped expectations to a regulated customer. PCI DSS enters separately if you touch cardholder data.
“We’re not APRA-regulated, so CPS 234 isn’t our problem.” Half right, and the wrong half is the expensive half.
CPS 234 is APRA’s prudential standard for information security. It binds APRA-regulated entities — banks, insurers, superannuation funds — not you. But its expectations reach you anyway, through the service-provider clauses those entities write into their contracts. Sign a deal with a bank and you inherit obligations shaped by the standard: the security capability you must maintain, what you must notify and when, what assurance they can demand from you and keep demanding.
That last part matters most. A regulated customer’s obligations are continuing, so their supplier oversight is too. The vendor review you passed at onboarding comes back — annually, after incidents, after contract changes — and their risk team has to stand behind your answers internally. “Trust us” doesn’t survive that. Verifiable evidence does.
ISO 27001 is the common way to evidence CPS 234-shaped expectations to a regulated customer. Not because the standard mentions APRA — it doesn’t — but because the contract clauses and the ISMS ask for the same things in the same shape.
| What the regulated customer’s contract asks for | What answers it |
|---|---|
| Evidence of a maintained information security capability | A certified ISMS — independently audited at Stage 1 and Stage 2, then every year at surveillance |
| Defined policies and controls, matched to what you hold for them | The Statement of Applicability: all 93 Annex A controls assessed, applicability documented and defensible |
| Incident handling and notification | An operating incident management process with records behind it, not a policy PDF |
| Assurance that holds over time, not at a point in time | The annual surveillance cycle and three-year recertification they can verify independently |
The compounding return: one certificate answers most of the security section of every regulated customer’s due diligence. The second bank’s review starts from your certificate and SoA instead of a blank questionnaire, and so does the insurer’s after that.
PCI DSS is the separate track, and it’s a fintech-specific trap to conflate the two. If your product stores, processes or transmits cardholder data, PCI DSS applies on its own terms, with its own scanning and audit-log obligations, and an ISO 27001 certificate doesn’t discharge any of it. Start with PCI DSS Requirement 11.3 on vulnerability scanning to see the difference in flavour: dated deadlines and named scan types, where ISO 27001 gives you risk-based judgement. Payments-adjacent fintechs commonly run both — the ISMS as the base layer, PCI DSS scoped tightly to the cardholder data environment.
Certification economics don’t change because you’re a fintech; the breakdown is in what ISO 27001 actually costs in Australia. And if you’re early-stage, the mechanics — small scope, one or two clouds, fast audit — are the same as in ISO 27001 for Australian SaaS startups. What changes in fintech is who reads your evidence, how often, and what they’re on the hook for when they accept it.
Treating each regulated customer’s due diligence as a one-off questionnaire exercise. A fintech burns weeks hand-writing answers for one bank, starts again for the next insurer, and the answers drift apart — different retention figures, different subcontractor lists — until a follow-up review notices the contradictions. Inconsistency reads as concealment, even when it’s just tiredness.
The correction: build one ISMS and make every questionnaire an extract from it. Same risk assessment, same Statement of Applicability, same incident records, referenced every time. Regulated customers re-review on a cycle, and consistency across rounds is part of what they’re checking. The fintech that answers from a system looks like a lower risk than the one that answers from memory — because it is.
We build and run the ISMS that regulated customers’ reviews land on. Our governance capability covers the risk assessment, policies, Statement of Applicability and the evidence trail; the same engagement runs the security operations behind it — monitoring, log retention, vulnerability management — so when the bank’s follow-up review arrives, the evidence already exists. Secure60 is ISO 27001:2022 certified ourselves and answers these questionnaires too. We know which answers get accepted and which ones trigger the meeting.
Does CPS 234 apply to my fintech directly?
Only if you’re APRA-regulated yourself. For most fintechs it arrives indirectly, through service-provider clauses in contracts with the banks, insurers and super funds the standard does bind.
Is ISO 27001 mandatory for Australian fintechs?
No law requires it. But it’s the common way to evidence security expectations to regulated customers, and many won’t complete vendor onboarding without certification or something equivalent to point at.
Do we need PCI DSS as well as ISO 27001?
If you store, process or transmit cardholder data, yes. PCI DSS applies on its own terms and ISO 27001 doesn’t substitute for it — see Requirement 11.3 on vulnerability scanning for a concrete example of what it demands.
Will an ISO 27001 certificate get us through a bank's vendor review?
It answers most of the security section and changes the tone of the rest. Expect follow-ups specific to the contract — incident notification, data handling, subcontractors — which your ISMS should answer from existing records, not fresh prose.
What does certification cost for a fintech?
The same market components as any Australian company of your size — see what ISO 27001 actually costs in Australia. What moves fintechs up the ranges is scope complexity, not the industry label.
