Information Security in Procurement: What to Require at Each Stage of a Technology Purchase

Security requirements added after a supplier has been chosen are requests. Added before, they are conditions. Most information security problems with suppliers trace back to a procurement that treated security as a questionnaire at the end. This guide to procurement information security sets out what to require at each stage of a technology purchase, using the controls in the Australian Government’s Information Security Manual as the checklist.

Why procurement information security starts before the tender

The Australian Signals Directorate’s Guidelines for procurement and outsourcing, part of the Information Security Manual (ISM), say supply chain risk management should happen during procurement itself, covering how a product or service is designed, built, delivered, operated, maintained and decommissioned. The same guidelines make a point that procurement teams sometimes miss: your obligations to protect data do not change when a managed service or cloud provider holds it.

The ISM is written for government, but its procurement controls are the most complete public checklist in Australia and translate directly to private sector contracts. Where this guide cites a control number, it is so your security and legal teams can look up the exact wording.

Stage 1: Plan and scope

Before anyone talks to a vendor, settle four things.

• What data is involved and how sensitive it is. Personal information, health records, payment data and operational technology each bring different obligations. The classification drives every later requirement.
• Who the suppliers in the chain are. ISM-1631 asks for suppliers of systems and services to be identified, and that includes the subcontractors behind a managed service.
• What a supply chain risk assessment needs to cover. ISM-1452 asks for an assessment of each supplier’s impact on the system’s risk profile, and ISM-1567 says suppliers assessed as high risk are not used. Decide now what would make a supplier high risk, so the decision is not made after a preferred vendor has emerged.
• Where jurisdiction matters. The ISM warns that offshore services and foreign-owned suppliers may be subject to foreign lawful access to customer data, and that foreign laws can change with little warning.

Stage 2: Approach the market

The request for proposal is where security requirements carry the most weight, because every respondent is still competing. Ask for evidence rather than assertions.

• Certifications with their scope. An ISO/IEC 27001 certificate means little until you know which sites, services and teams it covers. Ask for the certificate, its scope statement and the date of the last surveillance audit. For SOC 2 reports, ask for the Type II period covered.
• Government assessments where relevant. For government work, ISM-1793 and ISM-1570 expect managed and cloud services to undergo an IRAP assessment at least every 24 months.
• Data locations and subcontractors. Regions or availability zones where data is processed and stored, plus every subcontractor with access to it.
• The shared responsibility model. ISM-1569 asks for one to be created and shared. If a vendor cannot tell you in writing which controls are theirs and which are yours, that is an answer in itself.
• Security track record. ISM-1632 favours suppliers with a strong record of securing their own systems. Ask about notifiable incidents in the last three years and how they were handled.

Resist the 300-question spreadsheet. Long questionnaires reward vendors with large bid teams and produce answers nobody verifies. Twenty questions tied to evidence you will actually check are worth more.

Stage 3: Evaluate

Security should appear in the evaluation twice: as pass or fail gates, and as a weighted score.

• Gates are the non-negotiables set in stage 1: data residency, a minimum certification, no unresolved high risk from the supply chain assessment. A vendor who fails a gate is out, however good the price.
• Weighted criteria separate the vendors who pass. Maturity of their vulnerability management, quality of their incident response commitments, transparency about their own supply chain (ISM-1882) and how cleanly they can hand data back at exit.
• Verification is the step most often skipped. Check that the certificate scope actually covers the service being bought, read the SOC 2 exceptions rather than the summary, and ask references specifically about incidents and how the vendor communicated during them.

Our cybersecurity vendor evaluation framework covers scoring and weighting in more detail.

Stage 4: Contract

This is where security requirements become enforceable. The ISM’s section on contractual security requirements reads almost like a security schedule. Use it as a checklist against the vendor’s standard terms.

Two details matter more than they look. First, “as soon as possible” should be turned into hours where you have your own regulatory clock to meet. Second, the ISM notes that where a service has to go live before every requirement is in place, the contract should set timeframes for closing the gaps and a break clause if they are missed. Without that, the gaps tend to stay open for the life of the contract.

Stage 5: Onboard and operate

Security in procurement does not end at signature. The ISM expects organisations to keep a register of managed services (ISM-1736) and of outsourced cloud services (ISM-1637), each recording the provider, the purpose, the sensitivity of the data, the contractual arrangements, a 24/7 contact and the due date for the next security assessment. That last field is what turns a one-off due diligence exercise into an ongoing control.

Use the right to verify you negotiated. A clause that is never exercised carries little weight in a dispute and gives no warning before an incident. CYBORIUM supports organisations on these clauses through contract negotiation support.

Stage 6: Exit

The ISM recommends storing data in a documented format, preferably an open standard, because proprietary formats make backup, migration and decommissioning harder. At exit you also need the data deleted, and evidence that it was deleted, including from subcontractors and backups. Our guide to exit and transition-out costs explains how to price leaving before you sign.

Additional obligations for regulated organisations

• APRA-regulated entities. CPS 234 paragraph 16 requires an entity to assess the information security capability of any third party managing its information assets, in proportion to the consequences of an incident. Paragraph 35 requires APRA to be notified within 72 hours of becoming aware of a material incident, which is why supplier notification terms need to be faster than that. CPS 230 adds requirements for material service providers.
• Anyone buying systems that will run beyond 2030. The ISM retires RSA and elliptic curve cryptography after 2030. See post-quantum cryptography in procurement for the requirements to add now.
• Organisations covered by the Privacy Act. APP 11 requires reasonable steps to protect personal information, and APP 8 generally leaves you accountable for how an overseas recipient handles personal information you disclose to it. Under the Notifiable Data Breaches scheme you must assess a suspected breach within 30 days, so your supplier needs to tell you quickly enough for that to be possible.
• Critical infrastructure. Responsible entities under the SOCI Act must address supply chain hazards in their risk management program. See our note on the enhanced CIRMP rules for supply chain procurement.

Common mistakes

• Sending the security questionnaire after the commercial decision, when the vendor already knows it has won.
• Accepting a certificate without checking that its scope covers the service being bought.
• Agreeing incident notification “without undue delay” when your own regulator counts in hours.
• Negotiating an audit right and never using it.
• Forgetting subcontractors, who often hold the data and sit outside the contract.
• Leaving deletion and data return at exit undefined.

For the broader picture of supplier risk after the contract is signed, see what third-party risk management involves.

Procurement information security in practice

Procurement information security works when the requirements come first. Write the security conditions into the brief, score every supplier against them, and carry the same conditions into the contract. Review procurement information security again at renewal, because the controls a supplier runs change over time. Treated this way, procurement information security becomes a record you can show a board, not a questionnaire you file. Use this checklist for procurement information security on every technology purchase.

Frequently asked questions

What is procurement information security?

Procurement information security is the practice of setting, evaluating and contracting security requirements as part of buying technology, so that suppliers are chosen partly on their ability to protect your data and are bound to keep doing so. It covers planning, the tender, evaluation, the contract, ongoing assurance and exit.

Does the Information Security Manual apply to private companies?

The ISM is mandatory for many government bodies, and some government contracts pass its requirements on to suppliers. For other organisations it is voluntary, but its procurement and outsourcing controls are a practical and freely available checklist for any technology contract.

What security clauses should a technology contract include?

At minimum: documented security requirements, protection obligations extending to subcontractors, incident notification timeframes, a right to verify compliance, a break clause for security failures, data location and ownership, log access, data portability, and notice periods for supplier changes and service cessation. Our guide to buying data loss prevention applies these same clauses to a tool that stores its own copies of sensitive data, including who can view incident evidence and how long it is retained.

When should security be assessed in a procurement?

From the start. Set the security gates and criteria before approaching the market, request evidence in the tender, verify it during evaluation, and lock it into the contract before a preferred supplier is announced.

Official sources and update status

• Guidelines for procurement and outsourcing, Information Security Manual, Australian Signals Directorate (June 2026 release)
• Cyber supply chains, Australian Signals Directorate
• Prudential Standard CPS 234 Information Security, APRA
• APP 11 guidelines on security of personal information, OAIC
• APP 8 guidelines on cross-border disclosure, OAIC

Information status: control numbers checked against the June 2026 release of the Information Security Manual on 27 September 2026. The ISM is updated quarterly and control wording changes; this is general information rather than legal advice.

Running a technology procurement and want the security requirements built in from the start? Talk to CYBORIUM.

Last updated: 12 October 2026