ISO 27001 vs RFFR: What's the Difference?

It is easy to assume that Right Fit For Risk (RFFR) is just ISO 27001 with an Australian accent. After all, RFFR is built on an ISO 27001 management system, and many providers approach it as "ISO 27001, plus a few extra controls." That assumption is where a lot of organisations get caught.

RFFR does build on ISO 27001 — but the two are not the same, and the differences are not cosmetic. They change how often you work, what you are legally accountable for, and which controls you are allowed to risk-accept. This article walks through where they diverge and why those gaps matter.

First, what ISO 27001 actually is

ISO/IEC 27001 is a risk-based standard. In essence, it tells you how to build an Information Security Management System (ISMS), with risk management at its core. You achieve certification by meeting the standard's clauses and the Annex A controls applicable to your organisation — and crucially, how you choose to address those requirements depends on the level of risk you are mitigating and the type of environment you operate within.

That flexibility is the whole point. ISO 27001 does not hand you a fixed control set to bolt on. It gives you the blueprint and the high-level guidelines, then expects you to apply judgement based on your own risk profile. Two certified organisations can look quite different under the bonnet and both be entirely compliant.

Hold onto that idea — flexibility driven by risk — because it is exactly the freedom RFFR takes away in several important places.

Difference 1: Point-in-time certification vs a continuously operating ISMS

This is the divergence that surprises people most.

Once achieved, a standard ISO 27001 certification is comfortably maintained on set timeframes — annual risk reviews, periodic Statement of Applicability (SoA) reviews, scheduled internal audits, and surveillance audits on the certification cycle. The rhythm is predictable. You can plan your compliance calendar a year out.

RFFR is different in kind, not just in degree. It is about demonstrating a continuous ISMS operating model. Quarterly ISM updates, technological change, and evolving Departmental expectations all force your SoA to become a living document — reviewed and updated regularly throughout the year, not annually. That cadence has a knock-on effect: risk identification and assessment have to happen far more frequently. An annual risk review or once-a-year SoA refresh is simply no longer going to cut it.

Put another way: ISO 27001 gives you the blueprints and high-level guidelines to build the system. RFFR requires you to demonstrate your trajectory against a moving compliance maturity target. The goalposts shift with each ISM release, and your job is to show you are keeping pace.

If you treat RFFR as a tick-box compliance exercise — stand it up once, certify, and walk away — you are going to have a hard time both achieving and maintaining your certification.

Difference 2: The two-classification trap

Here is a subtle one that catches even experienced teams.

The Department specifies that providers must operate to the level of OFFICIAL: Sensitive. That is a protective marking under the Protective Security Policy Framework (PSPF), and it governs how the information must be secured — the handling, storage and access controls applied to it.

But the same information carries a second, overlapping classification. Under the Social Security Act 1991, much of the data providers handle meets the Act's definition of "protected information" (set out in its confidentiality provisions). This is not the PSPF "PROTECTED" classification that sits above OFFICIAL: Sensitive. It is a classification created by the legislation itself, and it governs how the information may lawfully be used and disclosed — backed by offence provisions for unauthorised use or disclosure.

So the same record is subject to two distinct frameworks at once:

• OFFICIAL: Sensitive (PSPF) — about how the information must be secured.
• Protected information (Social Security Act 1991) — about how the information must be lawfully handled.

One is a security obligation; the other is a legal one. They are separate operational and legal frameworks, and meeting your PSPF protective-marking obligations does not discharge your obligations under the Act. A provider that thinks only in PSPF terms can be technically secure and still on the wrong side of the legislation. This is precisely the kind of overlap a generic ISO 27001 program never has to contend with.

Difference 3: Core principles that ISO 27001 doesn't impose

RFFR's fundamental (or "core") principles add layers of control that a standard ISO 27001 certification simply does not require. Two stand out: data sovereignty and personnel security.

Data sovereignty, at a glance, restricts the geographical storage, processing and access of information to Australia. In practice that can mean:

• Privileged users — including any subcontractors — must be Australian citizens or permanent residents. Personnel security is no longer a "nice to have"; it is a gate on who can touch your environment.
• Your data must stay onshore. That might mean fitting your Microsoft tenancy with Advanced Data Residency (ADR) if you are eligible, or ensuring your data centres are based only in Australia.
• If you cannot meet those conditions, you need to demonstrate how you keep Protected Information segregated from the services that don't comply.

And here is the part that most clearly separates RFFR from the ISO 27001 mindset: contractual requirements do not fall under the risk-based approach. Under ISO 27001 — and even with the ISM controls layered on top — you can assess a risk, document it, and make a reasoned decision to accept it. The contractual obligations attached to your Deed do not work that way. They cannot be risk-assessed or risk-accepted. Data sovereignty is not a control you can decline because the residual risk looks tolerable. It is a condition of the contract. You either meet it or you demonstrate a compliant alternative.

That single distinction reshapes how you scope and govern the whole program. Anything driven by the contract sits outside the risk-acceptance machinery you are used to — and that is the trap for organisations approaching RFFR with a pure ISO 27001 playbook.

The bottom line

ISO 27001 and RFFR share a foundation, but they ask different things of you:

ISO 27001 gives you the system. RFFR takes that system, removes some of its flexibility, attaches legal and contractual obligations that sit outside your risk-acceptance process, and asks you to prove you are keeping pace continuously. Understand that going in, and you scope the work correctly. Treat RFFR as ISO 27001 with extra paperwork, and you will feel the difference at your first surveillance audit.