NSW Directive DCS-2025-04 and third-party risk: a practical checklist

Every major breach retrospective of the last five years has a chapter about a supplier. The vendor with a forgotten VPN account. The SaaS platform holding citizen data that nobody in the agency could name when asked. NSW's Directive DCS-2025-04 is the state's structural answer to that pattern. It pushes agencies to build and maintain real inventories of their third-party technology risk: knowing who their suppliers are, what those suppliers touch, and what would happen if one of them had a very bad day.

On paper this is unglamorous work. In practice it is the highest-leverage security task most agencies haven't finished, because you cannot assess, contract for, or test risk you haven't inventoried. And the inventory is hard: supplier relationships hide in expense reports and shadow procurement, sub-processors nest beneath the vendors you do know about, and the register you built eighteen months ago has been quietly rotting since the day it was finished.

The agencies that handle this well treat the directive as the front end of a pipeline rather than a reporting exercise. Inventory feeds risk-tiering, tiering drives the level of assurance each supplier owes you, and assurance obligations get teeth through contracts and through testing. That last step matters more than most compliance frameworks admit. A supplier's questionnaire answers are marketing until someone verifies them, which is where external attack-surface assessment and targeted penetration testing of critical suppliers' integration points earn their keep.

This post turns DCS-2025-04's requirements into a working checklist: how to find your suppliers, what fields an inventory needs to be useful rather than performative, a sane risk-tiering model, and how to sequence verification so your riskiest ten suppliers get real scrutiny instead of your easiest fifty getting a spreadsheet. Ironbark Cyber does supply-chain and third-party assessment work for government, and this is the shape of it done properly.

What does DCS-2025-04 require, in plain language?

Read past the reference number and the directive's intent is straightforward: NSW government agencies are expected to know their third-party technology suppliers, understand the risk each one carries, and manage that risk actively rather than discovering it during an incident. It sits under the broader NSW Cyber Security Policy and reflects a national and international shift, since regulators everywhere have concluded that an organisation's security is only as strong as the suppliers plugged into it.

In practice that translates to a small number of durable obligations: maintain an inventory of third parties and what they have access to, assess and tier their risk, hold them to appropriate assurance, and keep the whole thing current. The exact wording, thresholds and reporting cadence are set out in the directive itself and in NSW's guidance, so check those for the letter of the requirement. What follows is how to satisfy the intent in a way that reduces risk, which is a higher bar than satisfying the paperwork.

How do you find the suppliers you don't know you have?

The register you already have is the easy part. The risk lives in the suppliers that never made it onto it. To find them, triangulate from several directions rather than trusting any single source:

• Finance data. Accounts payable and expense reports surface recurring payments to technology vendors that procurement never formally onboarded.
• Identity and access. Your identity provider knows which external parties have accounts, federation trusts or guest access, often the fastest way to find a forgotten integration.
• DNS, certificates and your external footprint. Subdomains, SaaS tenancy records and TLS certificates reveal third-party platforms operating under your name. This is open-source reconnaissance and external attack-surface work, and it routinely finds suppliers no internal list contains.
• Sub-processors. The vendors you know about depend on vendors you don't. Their sub-processor lists and data-flow documentation extend the map a layer deeper.
• Ask the humans. Business units know the tools they rely on. A short, blunt survey ("what platforms do you rely on that IT might not know about?") surfaces shadow IT no dataset will.

Expect the real number to be several times your current register. That gap is not a failure of record-keeping; it is the risk the directive exists to surface.

What fields make the inventory useful rather than performative?

A register that lists supplier names and a contact is a phone book rather than a risk tool. To drive decisions, each entry needs enough to tier and act on:

The "data accessed" and "criticality" fields are what turn the register from a list into a risk-tiering engine. Without them you cannot answer the only question that matters: which of these suppliers could hurt us?

How do you risk-tier without a 40-page methodology?

Tiering should take minutes per supplier rather than a consultant's report. A simple model works: rate each supplier on the sensitivity of the data or access they hold and on how critical they are to your operations, and let those two axes place them in a tier.

• Critical. Holds sensitive citizen data, or has deep network and integration access, or your service fails without them. These get real, verified assurance.
• Important. Meaningful access or data, but contained blast radius. Assurance through evidence and contract.
• Routine. Little sensitive access; a register entry and standard terms are proportionate.

The point of tiering is to concentrate effort. Your riskiest ten suppliers deserve more scrutiny than your easiest fifty, and a model that treats every vendor identically guarantees you under-invest in the ones that matter.

How do you get from inventory to real assurance?

Tiering is only useful if it changes what you require of each supplier. Assurance runs on a ladder of increasing rigour:

• Contract. Security obligations, breach notification, right-to-audit and sub-processor disclosure written into the agreement. This is the foundation everything else stands on.
• Questionnaires and evidence. Self-assessment plus supporting certifications and reports. Useful for lower tiers, and a starting point for higher ones.
• Independent verification. For the critical tier, evidence someone has tested: a recent independent penetration test, an attestation, or your own testing of the integration.

The mistake agencies make is stopping at the questionnaire for suppliers who warrant the top rung. A questionnaire records what a supplier says about itself. For a supplier holding citizen data or wired into your network, that is not assurance; it is a claim awaiting verification.

How do you verify the critical tier?

For the suppliers that could genuinely hurt you, verify rather than trust. Two techniques do most of the work:

• External attack-surface assessment. Look at the supplier and their integration the way an attacker would: exposed services, weak configurations, leaked credentials, the forgotten VPN endpoint. Much of this can be done from the outside, without the supplier's involvement, and it frequently contradicts the questionnaire.
• Integration penetration testing. Test the connection between you and the supplier (the API, the data exchange, the trust boundary), because that is where a supplier compromise becomes your incident. This is targeted penetration testing of the seam rather than a full test of the supplier's whole estate.

You will not do this for every supplier, and you should not try. You do it for the critical tier, where the cost of verification is trivial against the cost of the breach it prevents.

How do you keep it alive?

Every third-party register decays. New suppliers arrive, access creeps, sub-processors change, and the document that was accurate at sign-off drifts from reality. Keeping it alive is a matter of ownership and cadence rather than heroics:

• Name an owner for the register itself, and an owner for each critical relationship.
• Trigger updates on events such as new contracts, renewals and offboarding, not only on a calendar.
• Re-verify the critical tier periodically, because a clean assessment eighteen months ago says little about today.
• Re-run discovery on a cadence; shadow IT regrows the moment you stop looking.

The checklist, in full

• Discover suppliers from finance, identity, external footprint, sub-processors and staff, rather than just the existing register.
• Capture the fields that enable tiering: data accessed, access type, criticality, sub-processors, assurance held, owner, last reviewed.
• Tier each supplier on data sensitivity and operational criticality into critical, important or routine.
• Match assurance to tier: contract for all, evidence for important, independent verification for critical.
• Verify the critical tier with external attack-surface assessment and integration penetration testing.
• Assign ownership, trigger updates on events, and re-run discovery and critical-tier verification on a cadence.

DCS-2025-04 is, underneath the reference number, a push to do the one piece of security hygiene that pays off every time a supplier fails: know your third parties, and verify the ones that matter. Ironbark Cyber helps NSW agencies and their suppliers turn the register into real assurance, discovering the third parties you can't see and testing the critical integrations where a supplier's bad day would otherwise become yours. The spreadsheet is the easy half; the verification is where the risk moves.