Most fintechs are not APRA-regulated, so CPS 234 does not 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 applies separately where you touch cardholder data.
CPS 234 is APRA’s prudential standard for information security. It binds APRA-regulated entities — banks, insurers, superannuation funds. Its expectations reach their suppliers through the service-provider clauses those entities write into their contracts, so a deal with a bank carries obligations shaped by the standard: the security capability you maintain, what you notify and within what period, and what assurance the customer can require on an ongoing basis.
The continuing nature of those obligations is the part that shapes the work. A regulated customer’s obligations do not lapse, so their supplier oversight does not either. The vendor review passed at onboarding recurs annually, after incidents and after contract changes, and the customer’s risk team has to defend your answers internally. Verifiable evidence is what supports that.
ISO 27001 is the common instrument for evidencing CPS 234-shaped expectations to a regulated customer. The standard does not reference APRA; the contract clauses and the ISMS ask for the same artefacts.
| 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 annually 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 |
| Assurance that holds over time rather than at a point in time | The annual surveillance cycle and three-year recertification, independently verifiable |
The return compounds across customers. One certificate answers most of the security section of every regulated customer’s due diligence, so the second bank’s review starts from your certificate and Statement of Applicability rather than a blank questionnaire, as does the insurer’s after that.
PCI DSS runs on a separate track, and conflating the two is a common fintech error. Where 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 discharges none of it. PCI DSS Requirement 11.3 on vulnerability scanning shows the difference: dated deadlines and named scan types, where ISO 27001 applies risk-based judgement. Payments-adjacent fintechs commonly run both, with the ISMS as the base layer and PCI DSS scoped tightly to the cardholder data environment.
Certification economics are the same for fintechs as for any company of the same size; the breakdown is in what ISO 27001 costs in Australia. For early-stage companies the mechanics — small scope, one or two clouds, fast audit — match those in ISO 27001 for Australian SaaS startups. What differs in fintech is who reads the evidence, how often, and what they carry when they accept it.
Treating each regulated customer’s due diligence as a separate questionnaire exercise produces drift. Weeks are spent hand-writing answers for one bank, the process restarts for the next insurer, and the two sets of answers diverge — different retention figures, different subcontractor lists — until a follow-up review identifies the contradiction. Inconsistency across rounds reads as concealment.
One ISMS, with every questionnaire extracted from it, removes that failure mode: the same risk assessment, the same Statement of Applicability, the same incident records, referenced each time. Regulated customers re-review on a cycle, and consistency across those rounds is part of what they assess.
We build and run the ISMS that regulated customers’ reviews examine. Our governance capability covers the risk assessment, policies, Statement of Applicability and the evidence trail, and the same engagement runs the security operations behind it — monitoring, log retention, vulnerability management — so the evidence exists before the bank’s follow-up review arrives. Secure60 holds ISO 27001:2022 certification and answers these questionnaires for its own platform, which is how we know which answers are accepted and which generate a meeting.
Does CPS 234 apply to my fintech directly?
Only where you are APRA-regulated yourself. For most fintechs it arrives indirectly, through service-provider clauses in contracts with the banks, insurers and super funds the standard binds.
Is ISO 27001 mandatory for Australian fintechs?
No law requires it. It is the common way to evidence security expectations to regulated customers, and many will not complete vendor onboarding without certification or an equivalent independent assurance.
Do we need PCI DSS as well as ISO 27001?
Where you store, process or transmit cardholder data, yes. PCI DSS applies on its own terms and ISO 27001 does not substitute for it — see Requirement 11.3 on vulnerability scanning for a concrete example of what it requires.
Will an ISO 27001 certificate get us through a bank's vendor review?
It answers most of the security section. Contract-specific follow-ups on incident notification, data handling and subcontractors are still expected, and your ISMS should answer them from existing records.
What does certification cost for a fintech?
The same market components as any Australian company of your size — see what ISO 27001 costs in Australia. What moves fintechs up the ranges is scope complexity rather than the industry.
