RFFR Core Expectations: What DEWR Asks Beyond ISO 27001 and the ISM

One of the clearest ways RFFR departs from a standard ISO 27001 certification is this: the Department of Employment and Workplace Relations (DEWR) publishes its own set of core expectations — a baseline of security requirements it places on providers delivering its services. These sit on top of your ISO 27001 management system and your ISM control set, and several of them are things a generic ISO 27001 or ISM program wouldn't necessarily produce on its own.

DEWR frames the core expectations as the minimum a provider must implement and manage to maintain and strengthen its security posture. They're published openly, and the current version lives on the Department's site: dewr.gov.au — RFFR Core Expectations.

This article walks through what those expectations actually cover, and why some of them catch providers off guard.

Personnel security

Bringing someone into an organisation that handles program data isn't just an HR formality under RFFR — it's a security control. The Department expects providers to:

• Confirm identity — positively establish who the person actually is.
• Verify competency — check the qualifications, certifications and experience claimed on their CV are real.
• Run a police check and obtain a satisfactory result.
• Complete Working with Vulnerable People checks where the relevant state or territory requires them.
• Confirm the right to work in Australia — anyone who isn't an Australian citizen must hold valid work entitlements.
• Deliver security awareness training — both initial and ongoing, with content and timing matched to the person's role.
• Bind information security and non-disclosure obligations into contracts that survive termination — the duty to protect information doesn't end when the employment does.

Then there's a heightened tier for anyone with privileged or administrative access. Because those individuals effectively hold the keys to your systems, the Department expects a higher level of assurance around them — including that they be Australian citizens or permanent residents (giving them a sufficient connection to Australia) and that they're willing and able to undergo a suitability background check. This is where personnel security and data sovereignty meet: who is allowed to hold the most powerful access is not left to discretion.

Physical security

Physical security expectations apply to every provider, and they're aimed at a simple outcome: information and physical assets shouldn't be able to be made unusable or inaccessible, or accessed, used or removed without proper authorisation.

Permanent facilities are expected to be commercial-grade and located within Australia. The Department defines a facility broadly — it might be a whole building, a single floor, or a designated area on a floor — but wherever government work is performed, the space needs appropriate physical protection.

The expectation that trips people up is working from home. Allowing staff to work remotely doesn't relax these obligations; it extends them. Providers have to consider how a home environment can be set up to protect staff, program data and IT assets to the same standard as the office. And it goes beyond the home: personnel using mobile devices to access or discuss program data — particularly in public spaces — are expected to stay conscious of their surroundings, taking care that conversations aren't overheard and screens aren't observed. In a distributed-work world, this is an easy expectation to overlook and a costly one to fail.

Cyber security

This is a parent category, not a single requirement — and that surprises providers who assume "cyber security" under RFFR just means the Essential Eight. It includes five distinct strands:

The Essential Eight. Providers adopt the ACSC's Essential Eight mitigation strategies, setting a target maturity level for each that reflects their own risk profile and planning how to reach those targets over time. The Department's starting floor is Maturity Level One across all eight. The strategies are application control, patching applications, configuring Microsoft Office macro settings, application hardening, restricting administrative privileges, patching operating systems, multi-factor authentication, and regular backups. (Which maturity level you actually need is a topic in its own right — the floor and the target are not the same question.)

Information security risk management. Embedding a formal, ongoing process to identify, assess and respond to the information security risks that arise specifically because of the Deeds.

Information security monitoring. Managing vulnerabilities and changes in a structured way — regularly surfacing new system vulnerabilities and remediating them promptly, with a change management process that lets the risk of each change be weighed, prioritised, tested and properly approved before it goes ahead.

Managing cyber security incidents. A formal incident management approach aligned to ISM guidance — built to detect and respond to incidents, report them internally and externally (including to the Department) where appropriate, and keep proper records. Logging security-relevant events and auditing those logs regularly is called out as a key part of detection. Note this expectation is about the capability: the hard notification deadline — as little as the next Business Day — lives in the privacy clause of your Deed, not in the RFFR material at all.

Restricted access controls. Measures that uniquely identify, authenticate and authorise everyone accessing your systems, with strong identification and authentication applied across all account types — standard user accounts, privileged accounts and service accounts alike.

The third-party trap: accountability doesn't transfer

This is the expectation most worth dwelling on, because it overturns a common assumption. A provider remains accountable for the security of its subcontractors. If a subcontractor delivers services on your behalf, you are responsible for ensuring they understand, implement and maintain a security standard that reflects your own obligations under the Deeds. Handing the work to someone else doesn't hand off the accountability.

The same principle extends to any external party that can reach your premises, systems or protected information. The example the Department gives is a sharp one: a Managed Services Provider administering your ICT systems almost certainly holds very high levels of access to those systems and the data inside them. That access makes them part of your security boundary, whether or not they're on your payroll.

The bar the Department sets is unambiguous: providers must ensure RFFR security requirements are in place and operating effectively throughout their supply chain. Not just contractually promised — actually working. This echoes the lesson from risk transfer: outsourcing a function never outsources the responsibility to verify it's being done properly.

What that means in practice — including why a subcontractor's own RFFR accreditation may not cover your services or arrive before your deadline, and why nobody is certifying your cloud choices for you — is covered in supply chain under RFFR.

Why the core expectations matter

Here's the strategic point. ISO 27001 gives you a management system. The ISM gives you a detailed control set. But neither, on its own, necessarily produces the specific baselines DEWR insists on: citizenship and permanent-residency requirements for privileged users, commercial-grade onshore facilities, home-working held to office standard, a minimum Essential Eight maturity, and demonstrable security across your entire supply chain.

These are contractual expectations, which means — as with the rest of RFFR's contractual layer — they aren't simply risk-based controls you can assess and accept your way around. They're conditions of delivering the Department's services. A provider can hold a clean ISO 27001 certificate and still fall short of the core expectations, because the core expectations ask for things ISO 27001 never specifically required.

The bottom line

The RFFR core expectations are where the Department spells out, in plain terms, the security baseline it needs from anyone handling its program data. They span personnel, physical, and cyber security, and they reach all the way through your subcontractors and service providers. Read them as the floor, not the ceiling — and read them early, because some (onshore privileged access, supply-chain assurance, office-standard home working) take real lead time to satisfy.

The official, current list is maintained by the Department here — always check it against your Deeds, as published expectations evolve.