The financial services attack surface
Financial institutions have spent a decade opening themselves up on purpose. Member portals, broker channels, mobile back ends, open banking interfaces and partner integrations all exist because customers and distribution demand them. Each one is also an entry point, and the pace of change means the map is never finished.
The pattern in most real incidents is unglamorous. An attacker does not defeat the core banking system directly; they obtain one valid credential, discover that the corporate network is flatter than the architecture diagram suggests, and move sideways until they reach something that matters. Proving whether that path exists in your environment is a different exercise from listing vulnerabilities, which is why attack path validation matters more here than raw finding counts.
The exposures that recur across banks, insurers, funds and fintechs:
- Internet-facing customer, member and broker portals, plus the mobile application back ends sitting behind them.
- Partner and open banking APIs where authorisation logic, not authentication, is the weak point that leaks other customers' data.
- Corporate networks where a single compromised workstation or service account can reach far more than the segmentation design assumes.
- Active Directory carrying over-privileged service accounts, stale administrator accounts and password policies that predate the current threat model.
- Cloud accounts and M365 tenants where a single over-permissive role or an identity gap is effectively the entire breach.
- Outsourced administrators and third parties holding standing access into systems your own staff would need approval to touch.
- Cardholder data environments where segmentation is documented and assumed, but has never actually been tested from the other side.
What regulators and counterparties expect
In Australia, APRA CPS 234 sets the tone for regulated entities. It expects an information security capability sized to the threat, clearly assigned responsibilities, controls that are systematically tested for effectiveness, and the same discipline applied to information assets managed by third parties. The word doing the work there is testing: not a policy document, but demonstrable evidence that controls were exercised and the results acted on.
If you store, process or transmit card data, PCI DSS v4.0 adds explicit penetration testing expectations: internal and external testing at least annually and after significant infrastructure or application change, plus segmentation testing where segmentation is relied on to reduce scope. Alongside these sit the Privacy Act and the Notifiable Data Breaches scheme, ISO 27001 programmes, the Essential Eight as a control baseline, and the due diligence questionnaires that arrive from every counterparty and enterprise client.
PentestOps is not a compliance certificate and does not make your organisation compliant with any of these. It produces the technical evidence those obligations depend on, with findings mapped to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes. Scope decisions and sign-off remain with you and your assessor.
| Driver | What it expects | How PentestOps supports it |
|---|---|---|
| APRA CPS 234 | Systematic testing of control effectiveness, including over information assets managed by third parties | Repeatable scheduled assessments across external, internal, application, identity and cloud, each with an audit trail |
| PCI DSS v4.0 | Internal and external penetration testing at least annually and after significant change, plus segmentation testing | On-demand or scheduled internal and external testing, with PCI DSS v4.0 mapping in the report |
| Privacy Act and Notifiable Data Breaches scheme | Reasonable steps to protect personal and financial information from unauthorised access | Exploit-validated evidence of what an attacker could actually reach, not a theoretical list |
| ISO 27001 programmes and internal audit | Technical testing that feeds the risk treatment cycle and closes out | Findings mapped to ISO 27001 with scan comparison showing issues verified as fixed |
| Counterparty due diligence | Recent evidence of testing, findings and remediation | Reports in PDF, CSV and JSON/API, retained 1 year on Starter, 3 on Professional and up to 7 on Enterprise |
Regulatory landscape
Financial services carries more named obligations than most sectors, and they overlap. The useful question is not which one a test satisfies, because none of them are satisfied by a test alone. It is what each obligation expects of your institution, and what evidence a test can put on the table against it.
PentestOps does not make your institution compliant with CPS 234, CPS 230, PCI DSS v4.0 or the Consumer Data Right, and it is not an assessor. What it produces is technical evidence. Scope, methodology sign-off and acceptance stay with you, your internal audit function and, where the obligation calls for one, your qualified assessor.
| Obligation | What it expects of you | Evidence a security test provides |
|---|---|---|
| APRA CPS 234, information security control testing | Controls tested systematically for effectiveness, at a frequency matched to how quickly the threat and the environment change | Repeatable scheduled assessments across external, internal, application, identity and cloud surfaces, each dated and backed by a full audit trail |
| APRA CPS 234, third-party information assets | The same control expectations applied to information assets managed by a third party, not only to systems you run yourself | External testing and continuous perimeter monitoring of the estate a provider exposes on your behalf, once their written authorisation sits in your rules of engagement |
| APRA CPS 230, operational risk management | Critical operations and material service providers identified, with controls tested and severe but plausible disruption scenarios considered | Validated evidence about the technology behind those operations: which exposures are genuinely reachable, and how far a single foothold moves laterally |
| PCI DSS v4.0, penetration testing of card data environments | Internal and external testing at least annually and after significant change, plus testing of segmentation where it is relied on to reduce scope | Internal and external assessments on demand or on schedule, PCI DSS v4.0 mapping in the report, and re-runs within fair use to exercise segmentation from the other side |
| Consumer Data Right (CDR) | An information security capability protecting CDR data, evaluated regularly and supported by independent assurance reporting | Validated findings against the systems and interfaces handling CDR data, including REST and GraphQL testing against OWASP API Top 10 risks |
From annual pentest to continuous validation
The annual penetration test was designed for environments that changed annually. Financial institutions now ship application releases weekly, spin up cloud resources daily and onboard partners continuously. A report written in March describes a system that no longer exists by June, and the gap between test cycles is exactly where new exposure accumulates.
A continuous programme closes that gap without discarding the formal test cycle. Scheduled assessments run at your chosen cadence, the perimeter is re-checked between them, assets are re-verified every 7 days, and drift detection records changes in a full change ledger. For background on the model, see what continuous penetration testing is.
Third-party exposure deserves the same treatment. CPS 234 is explicit that information assets managed by third parties are still your problem, and much of that exposure is visible from outside. External attack surface management continuously re-checks the internet-facing estate, including the forgotten subdomain a vendor stood up for a campaign two years ago. Testing systems a third party hosts always requires their written authorisation in your rules of engagement first.
How PentestOps maps to a financial institution
One platform and one asset-wise subscription covers the layers a financial institution actually exposes:
- Perimeter. 24+ external recon modules map what the internet can see across your domains and ranges, with no agent required for external testing.
- Customer applications. Web application testing against OWASP Top 10 risks, with a live finding stream rather than a report weeks later.
- APIs and open banking. API testing across REST and GraphQL against OWASP API Top 10 risks, focused on authorisation flaws between customer contexts.
- Internal networks and segmentation. An on-premise agent deploys in about 5 minutes, needs 0 inbound firewall rules and runs internal testing natively on the LAN instead of tunnelling every packet out to a remote scanner.
- Identity. Active Directory testing covers enumeration, credential testing and password-policy auditing, the usual bridge between one phished user and a domain-wide problem.
- Cloud. Cloud posture auditing runs 800+ automated checks across AWS, Azure, GCP and M365 using read-only credentials, mapped to CIS Benchmarks.
- Prioritisation. CVSS v3.1 scoring, exploit-availability indicators and CISA KEV prioritisation feed an exposure management view of what to fix first.
Typical use cases
- Banks, mutuals and credit unions proving that segmentation between corporate and core systems holds under a real foothold.
- Insurers and superannuation funds testing member portals, broker channels and the integrations behind them.
- Payment businesses and fintechs producing PCI DSS v4.0 mapped evidence before and after significant releases.
- Brokers, lenders and wealth managers answering counterparty security questionnaires with current evidence rather than last year's report.
- Security teams preparing for internal audit or APRA-driven control testing who need repeatable, documented assessments.
- Providers serving multiple financial clients from one console using the MSP security platform.
Why financial institutions choose PentestOps
Vulnerability management already tells you what might be wrong. The harder question, and the one a board or regulator actually asks, is what an attacker could do with it.
- Proof, not guesswork: exploitation is gated by per-tenant rules of engagement, scope enforcement automatically stops activity outside authorised assets, and validated findings carry an evidence trail.
- Chains, not lists: phased exploit chains show how one weak credential becomes a pivot, which is the finding that changes remediation priorities.
- Continuous coverage between formal assessments, so the gap after a release is measured in days rather than months.
- Self-hosted AI by default: scan data is analysed on infrastructure Extranet Systems operates and is not sent to third-party model providers. External providers are opt-in per tenant.
- Australian-built and operated. The platform is hosted in Australia, customer data is stored in Australia, and specific data-residency arrangements are available to Enterprise customers on request.
- Every customer runs in an isolated environment with its own dedicated database, with SSO available on Professional and Enterprise. Details are in the Trust Centre.
- Extranet Systems Pty Ltd is ISO/IEC 27001:2022 certified, independently audited by Atom Assurances, and operates SOC 2-aligned controls.
- Asset-wise pricing: pay for the assets in scope, with scans against them unlimited within fair use.