Supply Chain Under RFFR: Your Subcontractor's Accreditation Is Not Your Assurance

Most providers understand that RFFR reaches their subcontractors. Fewer understand how, and the gap between those two positions is where a Milestone 3 submission comes unstuck.

The Department's own guidance puts it about as plainly as a government document ever does: the organisation who is the deed signatory is legally and morally responsible for ensuring the subcontractors they use also comply with the security, privacy and data sovereignty requirements of the deed. A weakness in an entity in your supply chain is a risk to your organisation. Or, in DEWR's own words: don't leave a hole in your ISMS.

Accountability does not transfer. You can outsource the work. You cannot outsource being answerable for it.

This guide covers what that means in practice — including the timing trap that catches lead providers, the shared-obligations problem with TPES, and why no cloud certification gets you off the hook.

Your scope is bigger than your building

Start with scope, because supply chain is a scoping question before it is a supplier-management question.

The Department is explicit that "program data and related records" is a broad requirement — and that it is not limited to what you push into departmental systems. Emails. Calendar invitations. Reports you generate to run your own business. For the avoidance of doubt, DEWR states this includes:

• your own ICT environment
• any third-party IT systems you use
• any cloud services you use
• any interactions with Third Party Employment and Skills (TPES) systems you use
• the assurance mechanisms you rely on to gain confidence about the security operated by your subcontractors and service providers

Read that last bullet again. Your assurance mechanism is itself in scope. It is not enough to have a subcontractor who is secure — the way you know that is part of what gets assessed. "They told us they're fine" is an assurance mechanism, just a bad one.

This is also why the Department's scope guidance expects supply chain management to be described in your scope document as a named element, not left implicit.

The Deed draws the boundary wider than the guidance does

The published Deeds make this concrete, and they reach further than most providers assume.

They define an External IT System as any IT system or service other than the Department's own that is used by the Provider or any Subcontractor in connection with delivering the Services or accessing the Department's systems — expressly including your own systems and any Third Party IT. Your subcontractor's systems are not adjacent to your obligation. They are inside the definition.

Three duties attach to that, and they are contractual rather than advisory:

Tell the Department before you adopt or change one. You must advise securitycompliancesupport@dewr.gov.au of any proposed use of an External IT System to access departmental systems, and of any modification to its functionality that affects — or may affect — its security. The Department may impose terms and conditions, and you must ensure relevant subcontractors comply with them too.

Keep it onshore. Any External IT System used must not be accessible from outside Australia, and no data relating to the Services may be transferred to or stored outside Australia without prior written approval from the Department. The Inclusive Employment Australia wording goes slightly further again, adding accessed from outside Australia.

Be able to hand the records back. All Records held in any External IT System relating to the Services must be able to be provided to the Department on request, in unadulterated form — no amendments or transformations to the records or their data structures.

That second one deserves particular attention, because it is where a supplier decision quietly becomes a contractual breach. A support team in another timezone with admin access to your system is accessibility from outside Australia. That is not a theoretical risk to weigh — it is a term you signed. Check your Deed's exact wording, and where you need to operate differently, the mechanism is prior written approval, not a risk acceptance you write yourself.

One wrinkle worth knowing if you deliver Inclusive Employment Australia: that Deed is administered by DSS, but it names DEWR as the accreditation authority for the ESAF, and the RFFR requirements still apply. Two departments, one accreditation regime.

The timing trap: their accreditation may arrive after your deadline

Here is the one that catches lead providers, and it is worth reading twice.

Where the Department also holds a deed with a subcontractor you use, that subcontractor will be pursuing their own RFFR accreditation. It is tempting to treat that as solved: they're accredited, or will be, so that's covered.

DEWR's guidance flags two problems with that assumption.

Scope. Their accreditation covers their services under their deed. That may not be the same as the services they perform for you. An accreditation you didn't scope is assurance about something you might not be buying.

Timing. This is the sharp edge. If your subcontractor sits in Category 2A or 2B, their milestone deliverables to the Department may not fall due until a later date than your own submission. Their accreditation is real, and it is coming — after you needed it. You cannot borrow assurance that doesn't exist yet, and "our subcontractor is mid-accreditation" is not evidence you can put in front of an assessor at your Milestone 3.

So check two things about every accredited subcontractor: what their accreditation covers, and when it lands relative to your own dates.

Your actual options for subcontractor assurance

If their accreditation doesn't cover you, or doesn't arrive in time, the Department names two routes.

Include them in your own audit. Bring the subcontractor inside the scope of your audit and have your certification body test the controls at their sites too. Cleanest, and the most expensive.

Arrange a supplier audit — a second-party audit. You (or someone on your behalf) audit their environment directly. More work for you, less cost, and you control the timing rather than waiting on someone else's milestone.

Which fits depends on your situation: how critical the subcontractor is, how much of your program data they touch, and how much time you have. What isn't an option is a gap. If a subcontractor handles program data and you have no assurance mechanism you can evidence, you have a hole in your ISMS and the assessor will find it.

The mechanics of this are ordinary risk management: identify who touches your data, assess what that exposes you to, and treat it with an owner and a date. Supply chain is not a special discipline. It is your existing one, pointed outward.

If you're the subcontractor

The obligation runs the other way too, and the position is uncomfortable if you didn't expect it.

Your lead provider needs assurance you understand, have implemented, and will keep operating an effective standard of security across the life of your subcontracted services. They have to demonstrate their approach to supply chain security to the Department — and you are the evidence. Expect security-specific requirements in your subcontract, ISM-sourced controls to implement, and a reliable way of showing the lead provider you continue to meet their standard.

And there's a hard limit worth knowing: the Department does not assess or accredit organisations that are not signatories to a deed. If you don't hold a deed, there is no accreditation available to you to point at. Your assurance to your lead provider is a matter between you and them — which makes what you write into that subcontract, and what you can actually evidence, the whole of your position.

TPES: accredited does not mean absolved

First, check whether you have one — the definition is wider than the name suggests. The Guidelines define a TPES as any Third Party IT system used in association with delivering the Services, whether or not it accesses the Department's IT Systems, where that system either contains program-specific functionality or modules, or is used in any way for the analysis of Records relating to the Services or any derivative of them.

That second limb catches tools nobody thinks of as an employment system. A reporting or analytics product that never touches a departmental system, but chews through participant Records to produce management information, is inside the definition.

An accredited TPES then looks like the easy case. Its centralised controls have been accredited directly with the Department, and that accreditation can legitimately be leveraged as assurance the system is capable of being used securely for the specified programs.

But you need written approval to use or change one. The Guidelines are explicit: providers must obtain written approval from the Department to use or change a TPES. Not notify — approval. And if you want to use unaccredited software or services, that isn't forbidden, but it is on you: assess the risks, do your own evaluation, put controls in place.

Two more things then catch providers.

The interaction is yours. The connection between your environment and the accredited TPES — every transfer point — sits within the scope of your assurance. That's where you implement and manage configurations and users. The vendor's accreditation says nothing about how you wired yourself into it.

Your instance is yours. Providers must understand their own obligations for securing their instance, and ensure controls responding to these "shared obligations" are in the ISMS. Accreditation of the platform is not accreditation of your use of the platform.

The Guidelines turn this into a four-step duty. If you use a TPES, you must: access the relevant accreditation letter; understand the scope of that accreditation; identify whether your configuration matches the accredited configuration; and identify the risks of any unaccredited functionality you're using, and mitigate them.

So get the letter and actually read it. It specifies which programs and features are accredited, any action plans the vendor has for identified weaknesses, and any excluded features. Then compare it to how you actually use the thing. Where your use differs from the accredited configuration, that difference is yours to manage — and you will only know it exists if you've read the letter. The status of accredited TPES is published on the Department's Digital Information Assurance and IT Security Compliance pages.

Cloud: nobody is certifying this for you

If you are waiting for a list of approved cloud services, stop. ASD historically assessed centralised controls in cloud services on its Certified Cloud Services List — that list ceased in July 2020 and all ASD cloud certifications are void.

DEWR's position since is unambiguous: providers are wholly responsible for ensuring the cloud services they choose are appropriately secure and meet the unique requirements of their deeds — data sovereignty included. There is no list to hide behind.

And remember what the Deed already settled for you: a cloud service is an External IT System. So the onshore requirement is not a preference you weigh against price — not accessible from outside Australia, nothing stored offshore without prior written approval. That rules out a lot of otherwise excellent products, and it rules them out contractually rather than on a risk assessment.

The certification a cloud vendor waves at you needs the same scepticism as a subcontractor's:

• What is the scope of their certification, and does it match your usage? A certificate covering one region or one product line says nothing about the service you actually bought.
• Where is support delivered from? Data residency and data accessibility are different questions. A vendor can host in Sydney and still have engineers reaching in from three continents.
• What are the customer-specific responsibilities? Every shared-responsibility model leaves controls on your side of the line. Those are yours to implement, evidence and put in your Statement of Applicability — not the vendor's.

A vendor certificate is an input to your assessment. It is not the assessment.

The bottom line

RFFR's supply chain expectation is short to state and expensive to ignore: you are answerable for the security of everyone who touches your program data, and the way you satisfy yourself about them is itself in scope.

So keep a real register of who holds your information. Check that a subcontractor's accreditation actually covers your services and lands before your deadline — and have a second-party audit ready when it doesn't. Read the accreditation letter for any TPES you use, and own the transfer points and your instance. Assume nobody has certified your cloud choices, because since July 2020 nobody has. And check every External IT System against the onshore terms you actually signed, including where its support staff sit.

None of it is exotic. It is the discipline of knowing who you depend on, deciding what that risk is worth, and being able to show your work. As the Department puts it: don't leave a hole in your ISMS.