← All articles

Security questionnaire for healthcare software: Australian guide

Security questionnaire for healthcare software: Australian guide

Decorative title card illustration with healthcare security motifs

A compliant security questionnaire for healthcare software in Australia must map every control to TGA requirements, My Health Record conformance, and the ACSC Essential Eight, and it must demand documentary evidence, not self-attestation. Procurement teams that accept “yes/no” answers without artefacts are accepting risk, not managing it.

Mandatory evidence items your questionnaire must require:

  • Software Bill of Materials (SBOM) with component versions and known CVE status
  • Third-party penetration test report dated within 12 months, with CVSS scores and remediation notes
  • ISO 27001 certificate or SOC 2 Type II report
  • My Health Record conformance evidence (if the system connects to the national infrastructure)
  • MFA configuration documentation for all administrative and privileged accounts
  • ARTG listing or TGA evidence for any Software as a Medical Device (SaMD)

A vendor who cannot produce dated artefacts for each of these items within two weeks of receiving your questionnaire has told you everything you need to know about their security maturity.

Key takeaways

A compliant security questionnaire for healthcare software in Australia must demand dated documentary evidence mapped to TGA, My Health Record conformance, and the ACSC Essential Eight, with no substitutes accepted for SBOMs, penetration test reports, and MFA configuration proof.

Point Details
Demand SBOMs and pen-test reports Require a current SBOM and a third-party penetration test dated within 12 months as non-negotiable evidence items.
Map controls to Australian regulators Align every questionnaire domain to TGA Essential Principle 12.1, My Health Record conformance profile, and ACSC Essential Eight.
Apply a weighted scoring rubric Score 0–3 per question and weight encryption, MFA, and patching at 1.5× for My Health Record integrations.
Enforce session timeout and MFA thresholds My Health Record conformance requires session timeout no greater than 15 minutes and MFA as a mandatory capability.
Meddle as a secure platform choice Meddle integrates security and privacy controls by design, with transparent onboarding and documentation for procurement teams.

Table of Contents

What domains must a healthcare security questionnaire cover?

Patient safety depends on the integrity of the software clinicians rely on. A vendor security questionnaire that skips even one of the domains below creates a gap that regulators, auditors, and ultimately patients will find.

  • Authentication and MFA. Maps to ACSC Essential Eight (Restrict Administrative Privileges, MFA). Ask for MFA coverage on all admin accounts, not just user-facing logins.
  • Authorisation and access control. Role-based access, least-privilege enforcement, and audit trails. Relevant to My Health Record conformance and Privacy Act 1988 obligations.
  • Encryption at rest and in transit. The My Health Record conformance profile mandates ASD-approved cryptographic algorithms. Ask for the specific cipher suites in use.
  • Vulnerability management and patching. ACSC Essential Eight (Patch Applications, Patch Operating Systems). Require CVSS remediation thresholds and patch SLAs.
  • Logging and audit trails. Tamper-evident logs, retention periods, and alerting. Required for breach detection under the Notifiable Data Breaches scheme.
  • Secure updates and supply chain (SBOM). TGA guidance requires manufacturers to maintain SBOMs and manage supply-chain risk across the product lifecycle.
  • Third-party and cloud hosting. Data residency (Australian jurisdiction preferred), shared-responsibility model, and sub-processor list.
  • Business continuity and backups. Recovery time objectives, tested restore procedures, and geographic redundancy.
  • Incident response and breach notification. Written IR plan, notification timelines aligned with the Office of the Australian Information Commissioner (OAIC) requirements.
  • Privacy and data minimisation. Collection limitation, retention schedules, and de-identification practices.

For SaMD, escalate authentication, update pathway, and SBOM questions to your clinical safety lead. The risk profile of a clinical decision support tool differs materially from a scheduling SaaS, and your questionnaire should reflect that.

Core questionnaire by domain: sample questions and acceptance criteria

Use this section as a paste-ready starting point. Adapt question wording to your organisation’s risk appetite and the specific software category.

Identity and access management

  1. Describe MFA coverage for all privileged and administrative access. Which authentication factors are supported?
  2. How is role-based access control enforced, and how are access rights reviewed when staff change roles?
  3. Provide a screenshot or configuration export showing MFA is enabled for all admin accounts.

Encryption

  1. Which cryptographic algorithms protect data at rest and in transit? Confirm alignment with ASD-approved algorithms.
  2. How are encryption keys managed, rotated, and stored?

Vulnerability management

  1. What is your CVSS remediation threshold for critical and high vulnerabilities? What are your patch SLAs?
  2. Provide the most recent vulnerability scan report with remediation status.

Logging and monitoring

  1. How long are audit logs retained, and are they protected from tampering?
  2. Describe your alerting process for anomalous access events.

Secure updates and SBOM

  1. Provide your current SBOM, including third-party library names, versions, and known CVE status.
  2. How are software updates delivered, tested, and rolled back if they introduce a defect?

Supply chain and hosting

  1. Where is patient data hosted? Confirm Australian data residency or describe cross-border transfer controls.
  2. List all sub-processors with access to patient data and their security certifications.

Incident response

  1. Provide your written incident response plan and describe your breach notification process under the OAIC Notifiable Data Breaches scheme.
  2. What was the most recent security incident, and how was it resolved?

Privacy and data handling

  1. What data is collected, and what is the retention schedule for patient records?
  2. How is data de-identified for analytics or testing environments?

Clinical safety (SaMD)

  1. Is this software listed on the ARTG? Provide the ARTG number or evidence of TGA regulatory classification.
  2. How is cyber security risk managed across the product lifecycle per ISO 14971 and IEC 82304-1?
Requirement area Expected evidence Acceptance criteria Remediation timeline
MFA for admin access Config export or screenshot Pass: all admin accounts covered 30 days if partial
Encryption algorithms Policy doc + cipher suite list Pass: ASD-approved only 14 days
Vulnerability management Scan report + patch log Pass: critical CVEs remediated within SLA 30 days
Penetration testing Signed third-party report, dated within 12 months Conditional: older than 12 months with remediation plan Schedule within 90 days
SBOM Machine-readable SBOM file Pass: current, versioned, CVE-annotated 14 days
My Health Record conformance Conformance evidence letter Pass: conformance assessment complete Per ADHA timeline
ARTG listing (SaMD) ARTG number or TGA correspondence Pass: listed or exempt with evidence Per TGA process

Pro Tip: Ask vendors to supply artefact file names and dates rather than binary yes/no answers. A question phrased as “Provide the file name, date, and issuing body of your most recent penetration test report” is far harder to answer dishonestly than “Have you completed penetration testing?”

How to score vendor responses and spot red flags

A numeric rubric converts subjective answers into defensible procurement decisions. Score each question on a 0–3 scale: 0 for no evidence, 1 for policy only with no technical proof, 2 for partial evidence with a credible remediation plan, and 3 for complete, dated artefacts.

Weight the domains. Encryption, MFA, and vulnerability management carry the highest risk for My Health Record integrations and should be weighted at 1.5× when calculating a total score. Incident response and SBOM are weighted at 1.25×.

Mandatory evidence items that cannot be substituted:

  1. Signed third-party penetration test report dated within 12 months with CVSS scores
  2. Current SBOM with component versions and CVE annotations
  3. Documented encryption algorithms (ASD-approved) for data at rest and in transit
  4. MFA configuration proof for all administrative accounts
  5. Written incident response plan with OAIC-aligned notification timelines

Red flags that should fail a vendor outright:

  • Refusal to provide an SBOM or to allow third-party penetration testing
  • Plaintext credential storage or no encryption at rest
  • Patching windows exceeding 30 days for critical vulnerabilities
  • Data hosted in jurisdictions with weak data protection laws and no contractual safeguards
  • No written incident response plan
  • Inability to produce any ISO 27001, SOC 2, or equivalent certification

A vendor who claims Essential Eight alignment but cannot name the maturity level they target is offering checkbox compliance. Require a maturity level declaration and the evidence that supports it.

Australian regulatory obligations to build into your questionnaire

Three regulatory frameworks shape what your healthcare security assessment must cover in Australia.

TGA and SaMD. If the software makes or influences a clinical decision, it may be classified as SaMD and require ARTG listing. TGA guidance requires manufacturers to apply secure-by-design principles, maintain SBOMs, and demonstrate ongoing cyber security risk management across the product lifecycle. Essential Principle 12.1 specifically expects manufacturers to consider cyber security from design through post-market monitoring. Ask vendors for their ARTG number, their Essential Principle 12.1 compliance statement, and their process for notifying TGA when a vulnerability poses a significant safety risk.

My Health Record conformance. Systems connecting to My Health Record must satisfy the security conformance profile maintained by the Australian Digital Health Agency. The profile specifies mandatory and conditional requirements covering session management, MFA, encryption, and testing cadence. Conformance activities include a test specification and delivery of conformance artefacts before connection is approved.

Key thresholds from the conformance profile:

  • Session timeout defaults to a period of inactivity that requires re-authentication within a short time frame to enhance security
  • MFA is a required feature for all systems connecting to My Health Record
  • Encryption: ASD-approved cryptographic algorithms required
  • Penetration or vulnerability testing: at least every 12 months

ACSC Essential Eight and ISM. The Australian Cyber Security Centre’s Essential Eight provides the technical baseline for practice management software and clinical systems storing patient data. Ask vendors to declare their Essential Eight maturity level (ML1–ML3) and provide evidence for each mitigation strategy. The Information Security Manual (ISM) provides the control catalogue underpinning that maturity model.

The Digital Health Agency’s cyber security fundamentals also require My Health Record participants to maintain a written security and access policy. Confirm vendors support this obligation with policy templates or onboarding documentation.

Exact artefacts to request from vendors during evaluation

Demanding the right documents is what separates a genuine healthcare security assessment from a paper exercise. Request these in writing as part of your RFP response requirements.

Highest evidentiary value:

  • Signed third-party penetration test report (dated within 12 months, CVSS-scored, with remediation notes)
  • Machine-readable SBOM (CycloneDX or SPDX format preferred)
  • ISO 27001 certificate (with scope statement) or SOC 2 Type II report (full report, not summary)
  • My Health Record conformance evidence letter from the Australian Digital Health Agency

High value, typically available:

  • Vulnerability scan reports with remediation status
  • Encryption configuration documentation (cipher suites, key management policy)
  • Incident response plan (written, version-controlled, dated)
  • Data flow diagrams showing where patient data moves and is stored
  • Backup and restore test report (dated within 6 months)

Acceptable substitutes and escalation triggers:

If a vendor cannot produce an ISO 27001 certificate, a current SOC 2 Type II report covering the same scope is acceptable. If neither exists, request a vendor roadmap with compensating controls documented and a commitment date for certification. Treat the absence of both as a conditional fail requiring escalation to your CISO or clinical safety lead before proceeding.

For SaMD, the absence of an ARTG listing or TGA regulatory classification evidence is an automatic escalation, not a conditional pass.

Copyable security questionnaire template

Copy the sections below into your RFP or vendor onboarding pack. Add an “Evidence uploaded (Y/N)” column and a “Score (0–3)” column for reviewers. Export to CSV or Excel for scoring and audit trail purposes.

Section A: Identity and access management

  1. Describe your MFA implementation for all user, admin, and privileged accounts. Which factors are supported?
  2. How is role-based access control configured and reviewed?
  3. How are inactive accounts detected and disabled?
  4. Provide a configuration export or screenshot confirming MFA is active for all admin accounts.
  5. How are shared or service accounts managed and audited?

Section B: Encryption

  1. List the cryptographic algorithms used for data at rest and in transit. Confirm ASD-approved status.
  2. Describe your key management process, including rotation frequency and storage controls.
  3. How is data encrypted in backup and archive storage?

Section C: Vulnerability management and patching

  1. What is your CVSS remediation threshold for critical, high, and medium vulnerabilities?
  2. What are your patch SLAs for each severity level?
  3. Provide your most recent vulnerability scan report with remediation status.
  4. How are emergency patches tested and deployed without disrupting clinical workflows?

Section D: Logging and monitoring

  1. What events are logged, and how long are logs retained?
  2. How are logs protected from tampering or deletion?
  3. Describe your alerting and escalation process for anomalous access events.

Section E: Secure updates and SBOM

  1. Provide your current SBOM in CycloneDX or SPDX format.
  2. How are new CVEs in third-party components identified and remediated?
  3. Describe your software update delivery and rollback process.
  4. Are updates cryptographically signed? Provide evidence.

Section F: Supply chain and hosting

  1. Where is patient data hosted? Confirm Australian data residency or describe cross-border transfer controls.
  2. List all sub-processors with access to patient data and their security certifications.
  3. Provide your cloud provider’s shared-responsibility model documentation.
  4. How do you assess and monitor the security posture of third-party suppliers?

Section G: Business continuity and backups

  1. What are your recovery time objective (RTO) and recovery point objective (RPO) for patient data systems?
  2. How frequently are backups tested? Provide the most recent restore test report.
  3. Describe geographic redundancy for patient data storage.

Section H: Incident response

  1. Provide your written incident response plan.
  2. Describe your breach notification process and timelines under the OAIC Notifiable Data Breaches scheme.
  3. Describe the most recent security incident and how it was resolved.
  4. How are clinical safety leads notified in the event of a cyber incident affecting patient data?

Section I: Privacy and data handling

  1. What patient data is collected, and what is the retention schedule?
  2. How is data de-identified for analytics, testing, or training environments?
  3. How do you handle patient data deletion requests under the Privacy Act 1988?
  4. Provide your privacy impact assessment for this system.

Section J: My Health Record and regulatory compliance

  1. Provide your My Health Record conformance evidence letter or conformance assessment status.
  2. Confirm session timeout defaults are set to no greater than 15 minutes of inactivity.
  3. Describe how your system supports the written security and access policy requirement for My Health Record participants.

Section K: SaMD and TGA compliance (complete if applicable)

  1. Is this software listed on the ARTG? Provide the ARTG number or TGA regulatory classification evidence.
  2. Provide your Essential Principle 12.1 compliance statement.
  3. How is cyber security risk managed across the product lifecycle per ISO 14971 and IEC 82304-1?

For compliance audit readiness in long-term care and smaller clinic settings, the MyLTC Apps compliance checklist offers a useful operational comparison point, particularly for teams building their first vendor assessment process.

How to run the assessment: timelines, roles, and contract clauses

A questionnaire without a process is just a document. Structure the assessment as a defined workflow with named owners and fixed timelines.

Step-by-step assessment process:

  1. Issue the questionnaire with a cover letter stating mandatory evidence requirements and the submission deadline. Allow 2–4 weeks for vendor response.
  2. Internal triage (Days 1–5 after submission): security or IT lead reviews responses for completeness and flags missing artefacts.
  3. Technical validation (Days 6–15): verify artefact dates, check SBOM against known CVE databases, and confirm encryption algorithms against ASD-approved lists.
  4. Remediation window (up to 30 days for conditional items): issue a remediation register and require a written response with updated artefacts.
  5. Final acceptance decision: score against the weighted rubric, document the outcome, and obtain sign-off from your CISO or clinical governance lead.
  6. Contract execution: include security clauses before go-live.

Suggested contract clauses:

  • Ongoing vulnerability disclosure obligation within 72 hours of discovery for critical CVEs
  • Annual penetration testing with results provided to your organisation within 30 days of completion
  • Patch SLA commitments (critical: 14 days; high: 30 days; medium: 90 days)
  • Evidence update cadence: annual re-submission of ISO 27001 or SOC 2 report, SBOM, and pen-test report
  • Right to audit or request updated artefacts at any time during the contract term

Cost considerations. The hidden costs of a healthcare security assessment often exceed the questionnaire effort itself. Budget for third-party penetration testing fees if the vendor has not completed one recently, vendor remediation effort that may delay your go-live, and internal review time across security, legal, and clinical governance teams. A delayed go-live due to a failed assessment costs more than building the process correctly from the start.

How to run the assessment: timelines, roles, and contract clauses — overview diagram

Why questionnaires must be evidence-led, not checkbox exercises

The most common procurement mistake is treating a security questionnaire as a compliance formality rather than audit evidence. A vendor who ticks every box but cannot produce a dated artefact for a single control has demonstrated exactly the gap you were trying to find.

Evidence-led assessment means insisting on artefacts with dates, version numbers, and issuing bodies. A penetration test report from three years ago is not evidence of current security posture. An ISO 27001 certificate with an expired surveillance audit is not evidence of ongoing compliance. The questionnaire is only as strong as the verification step that follows it.

Meddle takes this seriously in its own vendor onboarding. Security and privacy controls are built into the platform’s design, not bolted on after the fact, and the same evidence-first standard applies when evaluating any third-party integration. That approach keeps clinician access fast while keeping patient data protected.

The proportionality point matters too. A small allied health scheduling tool does not carry the same risk profile as a clinical decision support system connected to My Health Record. Calibrate your questionnaire depth to the data sensitivity and integration scope of the software you are assessing. A 40-question template applied uniformly to every vendor wastes time and creates friction that pushes clinicians toward workarounds. Reserve the full template for high-risk integrations and use a streamlined version for lower-risk tools.

Meddle supports secure, compliant healthcare coordination

Procurement teams evaluating healthcare software need a platform that has already done the security work. Meddle’s practitioner benefits include privacy controls and secure digital health records built into the platform from the ground up, not added as an afterthought. For allied health clinics assessing vendor security alongside operational fit, Meddle offers a clear integration path with transparent security posture and a simple rollout starting from $25 per practitioner.

Meddle

Clinics that want to see how Meddle handles secure patient matching, referral coordination, and data protection can review the full platform overview at Meddle or contact the team directly to discuss security documentation and onboarding requirements.

Sources

Official Australian sources to bookmark for procurement and security teams:

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

FAQ

What is a security questionnaire for healthcare software?

A security questionnaire for healthcare software is a structured set of questions sent to a vendor to assess whether their system meets the security, privacy, and compliance standards required before procurement. In Australia, responses must be backed by documentary evidence mapped to TGA, My Health Record conformance, and the ACSC Essential Eight.

Hands holding tablet with healthcare items on desk

What evidence must a vendor provide for My Health Record integration?

Vendors connecting to My Health Record must provide a conformance evidence letter from the Australian Digital Health Agency, proof of MFA capability, ASD-approved encryption documentation, and a third-party penetration or vulnerability test completed within the past 12 months.

What is an SBOM and why does procurement need one?

A Software Bill of Materials (SBOM) is a machine-readable inventory of all software components, libraries, and versions in a product. TGA guidance requires SaMD manufacturers to maintain SBOMs so that vulnerabilities in third-party components can be identified and remediated quickly. Procurement teams should request an SBOM in CycloneDX or SPDX format.

How long does a vendor security assessment typically take?

Allow 2–4 weeks for the vendor to respond, 5–15 business days for internal technical validation, and up to 30 days for a remediation window on conditional items. High-risk integrations involving SaMD or My Health Record connectivity may require additional time for TGA or ADHA conformance verification.

What score should fail a vendor in a weighted security assessment?

Vendors who cannot produce mandatory artefacts (SBOM, penetration test report, MFA configuration proof) should be failed outright regardless of their total score.