ISO 27001 Certification While Modernising Legacy Systems

Security audit requirements are becoming a standing item on the technology roadmap for Australian fintech, healthtech and insurtech companies — often arriving at the same time as a legacy modernisation mandate. This guide walks through the ISO 27001 certification pathway in plain terms, how it differs from SOC 2, and why timing it alongside infrastructure modernisation work is a practical advantage rather than a scheduling headache.

What is ISO 27001?

ISO 27001 is the international standard for an Information Security Management System (ISMS) — a documented, risk-based framework for identifying, managing and continually improving how an organisation protects information. It is published by the International Organization for Standardization and, in Australia, certification is typically issued by a certification body accredited under the JAS-ANZ scheme. Certification signals to customers, regulators and partners that security is managed systematically, not ad hoc.

How is ISO 27001 different from SOC 2?

ISO 27001 certifies that an organisation operates a management system, while SOC 2 is an attestation report on the operating effectiveness of specific controls over a defined period. They overlap heavily in substance but differ in audience, format and renewal cadence, which matters when deciding which one (or both) your customers actually need.

Dimension	ISO 27001	SOC 2
What it is	Certification against an international management-system standard	Independent attestation report on control design/operation
Output	Certificate, valid for a fixed cycle with surveillance audits	Report (Type I or Type II) shared under NDA with customers
Primary audience	Global customers, regulators, procurement panels	US-heavy enterprise customers, SaaS buyers
Renewal pattern	Initial certification, then annual surveillance audits, recertification on a multi-year cycle	Re-issued report, typically annually, covering a new review period
Scope flexibility	Scope statement defines ISMS boundary; can be narrowed to specific products or environments	Scope defined by Trust Services Criteria selected (security, availability, confidentiality, etc.)

Many Australian companies selling into regulated sectors — banking, health, insurance — end up pursuing both over time, because different customers and procurement teams ask for different artefacts. Neither replaces a genuine security programme; both formalise one.

Why does legacy modernisation intersect with ISO 27001 readiness?

Modernisation and certification readiness solve adjacent problems: an ISMS needs accurate asset inventories, defined data flows and controlled access, and legacy environments — monoliths, undocumented integrations, ageing infrastructure — are exactly where those things tend to be weakest. Doing the two pieces of work together avoids documenting a system you are about to replace.

If your modernisation programme is already touching authentication, logging, network segmentation or data storage, that is also the moment to decide how those changes map to ISO 27001's Annex A controls. Retrofitting controls onto a legacy system you plan to decommission within twelve months is often wasted effort; building them into the new architecture is not. This is one of the reasons we treat security and compliance posture as an input to application modernisation planning rather than a separate workstream bolted on afterwards.

What does the certification pathway actually look like?

The pathway runs from scoping through two stages of external audit, followed by ongoing surveillance. It is iterative rather than a single project with a hard finish line, which is part of why it suits being planned alongside — not after — infrastructure change.

At a high level, the stages are:

1. Scope and gap analysis — define the ISMS boundary (which products, teams, environments and data are in scope) and assess current practice against Annex A controls.
2. Risk assessment — identify information security risks relevant to the defined scope and determine treatment options.
3. Statement of Applicability (SoA) — document which Annex A controls apply, which don't, and why, linked back to the risk assessment.
4. Implementation — put the policies, technical controls and operational processes in place, and generate the evidence (logs, records, training completions) an auditor will sample.
5. Internal audit and management review — test the ISMS internally before inviting an external auditor to do the same.
6. Stage 1 external audit — the certification body reviews documentation and readiness.
7. Stage 2 external audit — the certification body tests whether controls are actually operating as documented, typically through interviews, evidence sampling and site or system walkthroughs.
8. Certification and surveillance — once certified, periodic surveillance audits confirm the ISMS continues to operate, with recertification at the end of the cycle.

Timelines and costs vary significantly with scope, organisational maturity and how much of the ISMS already exists informally — there is no single figure that applies across fintech, healthtech and insurtech businesses of different sizes, so treat any quoted timeline as scope-specific rather than a fixed benchmark.

What should fintech, healthtech and insurtech teams consider specifically?

Sector context shapes scope decisions more than the standard itself does. Fintechs often need to reconcile ISO 27001 scope with APRA's CPS 234 information security requirements where they operate as or alongside a regulated entity. Healthtech organisations need their ISMS scope to align with Privacy Act 1988 obligations and, where relevant, state health records legislation. Insurtechs frequently face customer-driven security questionnaires that pre-empt formal certification, so early alignment between what customers are asking for and what the ISMS will cover avoids rework.

In all three sectors, the Australian Cyber Security Centre's Essential Eight provides a useful practical baseline that maps reasonably well onto a subset of Annex A controls, even though it is not itself a certifiable standard.

How should modernisation and certification work be sequenced?

Sequencing depends on which system the ISMS scope will cover first, and it is worth deciding this explicitly before either workstream starts, rather than discovering the conflict mid-audit. A few patterns we see work well:

• Where a legacy platform is being replaced within the certification timeframe, scope the initial ISMS around the target architecture rather than the system being retired.
• Where modernisation is multi-year, consider certifying the current environment first and expanding or re-scoping the ISMS as new components go live.
• Treat data flow mapping — a prerequisite for both data infrastructure work and ISO 27001 risk assessment — as shared groundwork rather than duplicated effort between the security and engineering teams.

This kind of sequencing decision is a good candidate for fractional or advisory input if your organisation doesn't have someone who has run a certification pathway before — our CTO advisory work often starts exactly here, helping technology leaders decide what to build now versus what to defer until after recertification.

Is ISO 27001 worth pursuing before or alongside an AI initiative?

If AI features are on your roadmap, it is worth deciding where they sit in ISMS scope before you ship them, since AI systems that process customer or health data typically fall inside the same risk assessment as the rest of the platform. This is a scoping conversation, not a reason to delay AI work — but it is easier to have before a new capability goes live than to retrofit afterwards. If you're planning AI features that touch regulated data, our AI engineering team can help you think through where those systems sit relative to your security posture.

Getting started

ISO 27001 certification is a structured, auditable commitment, not a quick checklist, and it rewards being planned alongside infrastructure change rather than after it. For more on related groundwork, see our other pieces in our insights on application modernisation patterns and data infrastructure fundamentals.

If you're weighing up an ISO 27001 pathway against a modernisation programme — or trying to work out which should come first — we can help. Start a conversation and we'll help you map the scope decisions before you commit a budget or a deadline to either.