The RFFR Statement of Applicability (SoA): A Living Document, Not a Filing Exercise

If there is one artefact that decides whether your RFFR accreditation stays healthy or quietly falls out of compliance, it is the Statement of Applicability (SoA).

And the single most important thing to understand about it is this: the SoA is a live document. It is not a policy or procedural document that sits in a folder and gets dusted off for review in the weeks before an audit. It is the working record of your security posture, and under RFFR it is expected to change continuously throughout the year.

Treat it as a once-a-year filing exercise and you will find yourself scrambling — out of date, out of step with the current ISM, and exposed at your next assessment. Treat it as the living instrument it is, and it becomes the control panel for your entire program.

The quarterly rhythm you have to keep

The Department issues a quarterly SoA aligned to the ISM control updates. Each release, you have to actually switch over to the new version and consider the new controls — you cannot keep running last quarter's SoA and catch up later.

"Consider" does not mean every control must be fully resolved the moment it lands. It means every new or changed control needs a deliberate, recorded response — even if that response is simply a comment noting that the control is under review, or recording who it has been assigned to for assessment. The point is that nothing is left unacknowledged. An empty or stale entry against a current ISM control is a gap; a documented "under review, assigned to [owner]" is a defensible position.

Where the action actually happens

A useful mental model: the Department's SoA template has several areas, and they move at very different speeds.

The RFFR Deed Obligations and the ISO 27001 Annex A controls are relatively stable — for the most part, they don't change much from quarter to quarter. You set them up well once and maintain them.

The ISM control list is where all the action is. The Australian Signals Directorate (ASD) updates the ISM quarterly, and each update can bring:

• New controls — additions you now have to assess for applicability and implementation.
• Reworded controls — existing controls whose meaning or emphasis has shifted, which may change whether and how you meet them.
• Rescinded controls — controls removed from the manual, which you retire from your active set.

Every one of these needs to be considered and reflected in your SoA each quarter. This is the engine room of RFFR maintenance, and it is precisely why the document can never be static.

Your environment changes count too

The ISM is only one source of change. The other is you.

Any change to your in-scope systems, processes, infrastructure or vendors can ripple straight into the SoA. Migrate a workload, swap a vendor, re-architect a process, onboard a new tool — if it sits within your ISMS boundary, it means updating the relevant SoA details and the evidence you rely on for attestation. The control may still be "Fully Implemented," but if the way you implement it has changed, the implementation details and supporting evidence have to change with it.

This is exactly why getting your scope right matters so much: your scope defines which environment changes are SoA-relevant in the first place.

The status rules: no empty rows, no middle ground

RFFR is strict about how controls are recorded, and the rules differ between Annex A and the ISM.

ISO 27001 Annex A controls under RFFR can only be Fully Implemented or Not Applicable. There is no partial state. RFFR requires all applicable Annex A controls to be implemented — so a control is either fully in place, or it is justifiably out of scope. Nothing sits in between.

ISM controls allow more granularity, but every status carries its own evidentiary burden:

The non-negotiable rule that ties this together: there should be no empty rows against any ISM control in the Department's SoA template. Every control gets a status and the evidence or explanation that status demands. A blank is not a neutral state — it reads as an unaddressed obligation.

The confusion that trips everyone up: Not Implemented vs Not Applicable

These two statuses sound similar and mean completely different things. Mixing them up is one of the most common — and most scrutinised — SoA mistakes.

Not Implemented means the control is applicable to your organisation and should be in place, but currently is not — typically due to operational or resource limitations. Because the control genuinely applies, you cannot simply leave it unaddressed. It must be supported by a risk treatment plan that sets out how you are handling the risk of the control not being in place: whether you will mitigate, transfer, avoid, or accept it.

Not Applicable means the control addresses something that does not exist in your organisation — it is guiding implementation against an activity or asset you simply don't have. The classic example is the secure software development control set: if your organisation does not develop applications in-house, most (if not all) of the controls in that category should be marked Not Applicable, with a short justification to that effect.

The distinction in one line: Not Implemented is a gap you have to manage; Not Applicable is a control that was never yours to meet. An auditor reading "Not Applicable" with no justification, or "Not Implemented" with no risk treatment plan, will treat both as findings.

The practice that makes all of this manageable

The reason the SoA feels overwhelming is that everything in it is connected to everything else — and most organisations maintain those connections in their heads, or not at all.

The discipline that changes the game: link your ISM controls to the risks, risk treatment plans, owners, applications, systems and assets they relate to. Build the relationships once, and maintenance becomes a query instead of a manual hunt.

When a vendor changes, you pull up every control linked to that vendor. When you retire a system, you immediately see which controls and evidence are affected. When ASD rewords a control, you know exactly which assets, owners and treatment plans need revisiting. The quarterly update stops being a full re-read of the entire SoA and becomes a targeted pass over only what actually changed.

That single practice — treating the SoA as a web of relationships rather than a flat list of rows — is what separates teams who stay continuously compliant from teams who rebuild their SoA in a panic every quarter.

The bottom line

The RFFR SoA is the heartbeat of your accreditation. It moves on a quarterly cadence driven by the ISM, it absorbs every relevant change to your environment, and it demands a defensible, evidenced status for every single control — with no blanks and no ambiguity between "can't yet" and "doesn't apply."

Maintain it as a living, connected document and it carries you through assessments with room to spare. Treat it as paperwork to tidy up before an audit, and it will be the first thing that gives you away.