Question:
Many iPaaS tools lack the native maturity for Complex Event Processing (FR-035) and Schema Governance (FR-038) and hence most organisations now separate iPaaS and eventing capabilities to gain a best-of-breed approach.

This helps eliminate the need for custom-code or sub-optimal workarounds typically required by single-vendor suites.

Would a response focused on a event streaming platform alongside WCQ's iPaaS choice be acceptable?

Answered on 11/Mar/2026 09:32 AM:


Morning Nathan,

In response to your questions please find below a reply.

Acceptance:

WCQ will accept and evaluate a submission that proposes an event streaming platform alongside the nominated iPaaS.

Submission expectations:

• Division of responsibilities: Clearly define the roles and accountability boundaries between the iPaaS, the event streaming/CEP layer, and schema governance components.

• Capability evidence: Provide substantiated evidence of maturity for Complex Event Processing (FR 035) and Schema Governance (FR 038/FR 039)—including methods, tooling, compatibility policies, and CI/CD enforcement.

• Compliance and operability: Demonstrate conformance with Australian data residency requirements and outline operability measures (e.g., availability, observability, disaster recovery).

Assessment approach:

WCQ will assess this best of breed model against FR 035, FR 038/FR 039, and relevant NFRs, with a preference for solutions that avoid custom code or sub optimal workarounds.

Kind regards

Scott

Question:
Cloud Provider: While Azure AD is used for identity, which Cloud Service Provider will WCQ use?

Networking: Does WCQ have a preference to the type of private networking to be used?

Throughput Metrics: What throughput does WCQ expect (or message sizes + messages per day / hour / etc) from pub-sub/event streaming?

Connectors: What are the systems (to and from) does WCQ expect to connect to? e.g. Salesforce, etc

Data Retention: What are the expected data retention requirements for the event topics (e.g., hours, days, infinite)?

Environment Landscape: The pricing section mentions Non-Prod (Dev/Test), Pre-Prod, Prod, and DR. How many distinct Confluent clusters/environments are anticipated across these lifecycle stages?

Platforms: What are the specific primary SaaS platforms and legacy systems (aside from CPIS) that the integration platform will need to connect to in Transition State?

Availability: What’s availability requirements such as 99.9% or 99.99%?

RTO/RPO: What is the target Recovery Point/Time Objective (RPO/RTO)? Should the architecture be resilient against a single Availability Zone (AZ) outage, or is full Regional failover a requirement?

Answered on 18/Mar/2026 01:43 PM:


Afternoon Nathan,

Please find response to your clarifications sort as follows:


1. Cloud Provider:

WCQ uses AWS as its primary cloud provider however this should not preclude a submission proposing an integration platform dependent on a different cloud provider



2. Networking:

WCQ does not prefer any type of private networking referred to in FR-004, and will accept and evaluate a submission that describes how a chosen approach will protect and affect network traffic



3. Throughput metrics:

If throughput is a factor, responses to FR-011, FR-012, FR-013 should include how it will affect the pub-sub/event streaming behaviour of the integration platform



4. Connectors:

WCQ may acquire multiple new operational systems from major SaaS providers to deliver any capability defined by FR-014. WCQ will accept and evaluate submissions that describe corresponding OOTB connectors that are compatible with the integration platform.

5. Data Retention



Suppliers are requested to describe a recommended data retention strategy by topic class, including operational and cost considerations.

- Retention targets: Specify default and maximum retention for:

- Transactional / operational topics (typical replay windows)

- Reference / configuration topics (e.g. log-compacted)

- Audit / forensic streams (extended retention and/or archive tiers)

- DLQ / quarantine topics (retained until triage and remediation)

– Policies & mechanics: Confirm support for delete and log-compaction policies and how these interact with retention windows.

– Tiering & archive: Describe hot vs archive/cold storage options, including re-hydrate/replay processes and applicable SLAs.

– Observability & governance: Explain how retention settings are defined and governed as code, audited, and exposed to FinOps for forecasting and alerting.

– Non-Prod defaults: Provide recommended lower-cost Non-Prod defaults (e.g. reduced replicas), including any caveats.

Expected artefacts: Retention matrix by topic class; configuration/policy examples; cost sensitivity analysis (retention vs GB/month).



6. Environment Landscape



Suppliers should propose a minimum risk, cost aware environment topology aligned to the pricing model covering Non Prod (Dev/Test), Pre Prod, Prod and DR.

– Topology options:

o Option A: Dev + Test shared; Pre Prod dedicated; Prod dedicated; DR stance (warm/cold).

o Option B: All stages dedicated, with justification of risk and cost trade offs.

– Fault domains: Confirm multi AZ deployment for Prod as a baseline, and note any deviations for Non Prod and Pre Prod.

– Control vs data plane: Identify any control plane tenancy limits that require environment separation.

– Isolation & quotas: Describe multi tenant isolation (projects/teams), quotas and governance mechanisms (e.g. topic naming, ACLs).

– DR environment: State whether DR uses separate clusters and/or regions, the replication approach, and the cost to maintain readiness (warm vs cold).

Expected artefacts: Environment topology diagram; platform vs application RACI; sizing guidance (partitions, replicas, brokers per stage).





7. Platforms:

WCQ may acquire multiple new operational systems from major SaaS providers to deliver any capability defined by FR-014. Some or all of these may be part of a transition state operating in parallel with CPIS.


8. Availability (SLA / SLO)

Suppliers should state availability targets and operational posture for each major component.

– Targets: Provide monthly SLA/SLOs for brokers/event backbone, schema registry, control-plane/console, and managed connectors, including options (e.g. 99.9% vs 99.99%) and dependencies (multi-AZ, replica counts, client configuration).

– Maintenance & changes: Describe planned maintenance windows, rolling upgrades, and mechanisms used to minimise or avoid downtime.

– Failure behaviour: Explain producer/consumer failover behaviour, backlog handling during broker or node loss, and safeguards against data loss.



Expected artefacts: SLA documentation; upgrade and maintenance runbooks; historical availability evidence (last 12–24 months) where available.





9. RTO / RPO and Failure Scenarios



Suppliers are requested to provide RTO/RPO targets and failover design for key failure modes.

– AZ outage (in-region):

– RPO: Target data loss (e.g. zero or bounded by ISR/acks configuration).

– RTO: Time to restore service and drain backlog.

– Mechanisms: Replication factor/ISR, partition placement, leader election, client retry/failover, DNS or connection routing.

– Regional loss (within Australia):

– RPO/RTO targets and failover model (active/active or active/passive warm/cold).

– Mechanisms: Cross-region replication, schema/subject replication, secrets and identity synchronisation, switching runbooks and operator actions.

– Test evidence: Describe DR test frequency and scope (brokers, registry, connectors) and how evidence is provided for CAB/RMB.



Expected artefacts: DR architecture; RTO/RPO table; replication and client-failover configuration; sample DR test reports.





Additional Guidance

- Requirements mapping: Reference FR-035 (CEP), FR-038/FR-039 (Schema Governance) and relevant NFRs (availability, DR, compliance, observability, FinOps).

- Assumptions & cost transparency: Clearly state assumptions for each option and provide price deltas to support comparison.

- Australian data residency: Confirm that production data, operational telemetry, backups and DR replicas remain within Australia, and describe the controls enforcing this.

Kind regards

Scott McNeil

Question:
Scope: B

Category: Pricing Model

Question: For Scope B professional services, do you have a preferred commercial model (e.g. milestone-based fixed price per phase, fixed price packages, or capped T&M), provided that it remains time-limited, transparent and avoids open-ended commitments?

Answered on 19/Mar/2026 02:19 PM:


Afternoon Shefreen,

In response to your questions I provide the following detail:

Response:


Scope B — Pricing Model (Professional Services):

· Accepted models (time-limited and transparent):

o Fixed-price packaged services (preferred) for well-defined deliverables (e.g., platform setup, accelerators, onboarding, enablement bundles).

o Milestone-based fixed price (per phase) with clear deliverables and acceptance criteria (e.g., TS1/Stage-1 mobilisation, reference integrations, handover).

o Capped Time & Materials (T&M) for tightly bounded advisory/coaching, with a not-to-exceed cap.

· Not acceptable:

o Open-ended T&M or models without a cap.

o Auto-renewing blocks or undefined scope without WCQ approval.

· Commercial conditions (apply to all models):

o Time-boxed engagements with defined start/end; extensions by prior written approval.

o Transparency: itemised pricing (by role/grade and package/milestone), on/offshore mix.

o Knowledge Transfer (KT): KT hours visible (by role/topic) with acceptance criteria for capability uplift.

o Change control: documented variations before additional charges accrue.

o T&E: stated upfront; pre-approved; at cost where applicable.

o Invoicing: tied to accepted milestones/packages, or monthly actuals for capped T&M with burn-up against the cap.

o Rate card (for capped T&M): role/grade, day rate, minimum increment, weekly cap, onshore/offshore, time-zone/public-holiday considerations.

o Price validity & indexation: validity period; any indexation (e.g., CPI) clearly specified (basis and timing).

o Assumptions/dependencies: client prerequisites that affect price/schedule.

· Supplier response — what to include:

o The model(s) proposed per workstream (package FP / milestone FP / capped T&M) and rationale.

o Scope & deliverables, KT hours, acceptance criteria, timetable, and fixed price (for FP) or cap and rates (for T&M).

o Risk/contingency, T&E policy, and any exclusions/optional services priced separately.



Kind Regards

Scott McNeil

Question:
Scope: A/B

Category: Security & Compliance

Question: Beyond ISO 27001 and Australian data residency, are there any additional regulatory or policy requirements (e.g. specific Queensland Government information security standards, data retention rules) that materially affect integration design?

Answered on 26/Mar/2026 11:56 AM:


Hi Shefreen,

Workcover Queensland is a statutory body subject to Qld Government obligations such as:

· IS18 – Information & Cyber Security Policy

· The Information Privacy Act 2009 (Qld) (IP Act)

· Queensland Government Enterprise Architecture.



WorkCover Qld also aligns to the Australian Government Information Security Manual (ISM), ISO27001, NIST Cyber Security Framework, APRA Prudential Standards for Security and Operational Risk Management.

Kind regards

Scott McNeil

Question:
scope: B

Category: Roles & Locations

Question: Do you have expectations on the mix of on-site (Brisbane) vs remote delivery for key roles (Architect, PM, Developers) during platform establishment and TS1? Is on-shore and off-shore model allowed?

Answered on 19/Mar/2026 02:23 PM:


Afternoon Shefreen,

In response to your question WCQ provide the following reply:

Response:

Scope B — Roles & Locations (Professional Services):

· Position: WCQ has preferred for an on-site, Brisbane-based delivery during platform establishment and TS1 to enable rapid mobilisation, close collaboration, and effective knowledge transfer.

· Working cadence & time zone:

o Operate on AEST (Brisbane), with in-person attendance for planning, refinement, showcases, cutovers, and KT.

o Remote days must maintain real-time overlap for pairing and incident response.



· On-shore vs off-shore:

o On-shore model required for platform establishment and TS1 across key roles (Architect, PM/Delivery, Security SME, Technical Lead, Lead DevOps/Platform, Developers for first delivery lanes).

o Off-shore not permitted for TS1 and cutover-critical activities.

o Post-TS1 (by exception): limited off-shore may be considered for non-production, non-sensitive work (e.g., documentation, templating) with prior approval, no Prod access/PII, sanitised datasets, and clear on-shore control/hand-back.

· Resourcing standards (all roles):

o Brisbane-based (or regularly on-site) with valid work rights; named primary and deputy per key role.

o Security & compliance: background checks; adherence to WCQ policies; mandatory inductions before access.

o Travel & Expenses: if not local, proposals must include T&E and an on-site schedule commitment.

· What to include in supplier responses:

o Role-location matrix for Establishment and TS1 (name, role, primary location, on-site % per sprint).

o On-site roster & cadence (which ceremonies are in-person), plus escalation/coverage model.

o Mobilisation plan (first 4–6 weeks) covering co-location with squads, KT plan/artefacts, and decision forums.

o Substitution policy and cutover contingency.

o If proposing any post-TS1 off-shore: scope boundary, data controls (sanitisation), access restrictions, and handover protocol to the on-shore team.


Kind regards

Scott McNeil

Question:
Scope: B

Category: Knowledge Transfer

Question: How do you prefer knowledge transfer to be structured (e.g. formal training, pair programming, shadowing/reverse shadowing ratios, documentation expectations) to consider adoption risk addressed?

Answered on 19/Mar/2026 02:29 PM:


Afternoon Shefreen,

Please find response to your clarification on knowledge transfer:

Scope B — Knowledge Transfer (KT):

· Objective: Make WCQ self-sufficient from the end of TS1, reducing adoption risk and vendor dependency.

· Methods (blend):

o Formal, role-based sessions with short labs and recordings.

o Pairing/clinics on real TS1 items (pipelines, policy-as-code, gateways, connectors, observability).

o Shadow ? reverse-shadow progression (vendor-led to WCQ-led).

o Artefact walkthroughs (reference architectures, ADRs, runbooks, DR playbooks, CI/CD templates, policy packs).

· Cadence & ratios (baseline):

o Shadowing to reverse-shadowing shifts from 70/30 ? 30/70 across TS1.

o Pairing: ~2 half-days/week in early sprints, taper as capability is proven.

o Sessions: Focused =90 minutes, repeat for shift coverage.

· Documentation (must-deliver):

o Runbooks (install/upgrade/rollback, incident, DR/cutover).

o Operational artefacts (RACI, on-call, dashboards/alerts, cost guardrails).

o Engineering assets (CI/CD, policy templates, naming standards, smoke/contract tests).

o Knowledge base (wiki, FAQs, ADR index, “first 90 days” guide) in version-controlled repos with named owners and update cadence.

· Acceptance & KT hours:

o Visible KT hours itemised by role/topic (incl. prep).

o Readiness checks: WCQ independently deploys, recovers common incidents, and operates dashboards/cost controls.

o Handover pack: recordings, slides, labs, runbooks, configs, plus a completion report mapped to acceptance criteria.

· On-site vs remote for KT:

o Brisbane on-site by default for workshops, design reviews, reverse-shadow, cutovers and DR tests; remote suitable for documentation and follow-ups with AEST overlap.

· Post-TS1 sustainment:

o Weekly office hours for ~4 weeks, targeted mini-clinics, and 30/60/90-day artefact refresh.

Supplier Response — include: KT plan (catalogue, audience, materials, KT hours), shadow/reverse-shadow schedule aligned to TS1 backlog, acceptance matrix and proof points, artefact inventory (repo/Wiki), and risks/mitigations (backfill, access pre-reqs).

Kind regards

Scott

Question:
Scope: B

Category: Delivery Model

Question: How do you envisage the split of work between the WCQ integration team and the supplier’s team during establishment (e.g. approximate percentage of work done by WCQ vs supplier across design, build, testing)?

Answered on 19/Mar/2026 02:31 PM:


Afternoon Shefreen,

Please see the response to your Clarification:

Scope B — Delivery Model (Establishment & TS1):

· Principle: Start supplier-led for speed and risk reduction; swing rapidly to WCQ-led through structured pairing and reverse-shadowing so WCQ is self-sufficient by the end of TS1.





· Phase 1 — Platform Establishment (to first Non-Prod cut)

o Design: Supplier 60–70% | WCQ 30–40%

o Build/Automation: Supplier 65–75% | WCQ 25–35%

o Testing/Hardening: Supplier 55–65% | WCQ 35–45%

· Phase 2 — TS1 (enablement & first use cases)

o Design: Supplier 40–50% | WCQ 50–60%

o Build: Supplier 40–50% | WCQ 50–60%

o Testing: Supplier 30–40% | WCQ 60–70%

· Phase 3 — Stabilisation & Handover

o Design/Build/Run: Supplier 20–30% (assurance, complex reviews) | WCQ 70–80% (BAU, ops, releases)

· Notes:

o Percentages are indicative and flex with scope/maturity.

o Supplier leads early guardrails/quality gates; WCQ owns backlog, domain decisions, UAT.

o Embedded KT (pairing ? reverse-shadowing) underpins the shift to WCQ-led delivery.

Kind regards

Scott McNeil

Question:
Hi,


Section 1.8 of the Invitation to Offer, lists a Non-Disclosure Agreement (NDA) under Part D as a document that the Supplier must complete and return with its Offer.

The NDA document does not appear to have been included in the tender package made available to Suppliers via VendorPanel.

Could WorkCover Queensland please provide the NDA document at the earliest opportunity to allow sufficient time for review and execution prior to the closing date of 10 April 2026?

Answered on 20/Mar/2026 12:49 PM:


Hi Kayla,

I have updated the document list with the Non Disclosure agreement into the ITO documents.

Kind regards

Scott McNeil

Question:
Hello

1. In the documents there are references to Transition State 1 (TS1) activities and milestones, that include varying references to enablement, use cases and other items. Could you please provide a clear scope of TS1?

2. Phase 1 scope refers to 'first non-Prod cut'. Does this imply that WCQ will take ownership of provisioning and deployment to higher environments?

3. In Part B 1.10 Integration Patterns reference is made to API Gateway rules and use of 'the WCQ API Gateway'. Is this already in place, and if so, can you please advise the technology?

Kind regards

Answered on 23/Mar/2026 02:35 PM:


Afternoon Simon,

Response:

1. The Transition State 1 scope will involve a combination of current and target state applications. The iPaaS must be able to support any integration solutions required for TS1 including but not limited to the exposure of current services as new APIs, intermediate data transformation, and different forms of data movement.

2. WCQ has exclusive responsibility over the production environments and the provisioning and deploying of the iPaaS solution in that environment. This may be extended to pre-production. The supplier is expected to implement the iPaaS in lower environments and provide sufficient guidance to permit WCQ resources to successfully promote the iPaaS from there.

3. Any reference to “the WCQ API Gateway” applies to a conceptual API gateway. To respond to the RFP, the supplier can assume this refers to the API gateway that will be delivered as part of the iPaaS implementation

Kind regards

Scott.

Question:
Hello, please see below questions:

1. Does WCQ have a preferred organisational change management framework already in place that the vendor should be aligned with to ensure enterprise-wide adoption of the new platform?

2. What is the anticipated availability and dedication level of the internal integration team members throughout the platform uplift?

3. What metrics does WCQ intend to use to evaluate the long-term sustainability and effectiveness of the capability uplift within the internal integration team?

4. How does WCQ prefer to validate that internal integration team have reached the required level of proficiency?

5. Can WCQ clarify its preferred approach to cost management, including expectations regarding capacity-based versus consumption-based pricing models and associated forecasting or cost control requirements?

6. Can WCQ outline its current and target-state operating model for integration delivery, including expectations for central governance versus domain-level autonomy?

7. Can WCQ confirm the expected division of responsibilities between the platform provider and WCQ for edge components such as load balancing, WAF and private networking infrastructure?

Answered on 24/Mar/2026 11:15 AM:


Morning Aislinn,

In response to your clarification please see below:



1. Organisational Change Management (OCM) framework

? WCQ does not mandate a single OCM framework. Vendors may use an industry-standard approach provided it is outcomes-based and tailored to WCQ.

? Minimums: Stakeholder map & comms plan, role-based enablement plan, adoption KPIs, risk register, and a release/change calendar linked to TS1/production gates.

? Deliverables: Training materials, quick-reference guides, adoption dashboards, and a benefits realisation plan.



2. Internal team availability/dedication (Establishment ? TS1)

? Baseline allocations (indicative):

? Product Owner / Platform Lead / Solution Architect: 60–80% during Establishment; 60–70% in TS1.

? Security / Network / Identity SMEs: 40–60% (spiking around design reviews, cutovers).

? Integration Engineers (WCQ): 40–60% Establishment; 60–70% in TS1 (ramping via pairing ? reverse-shadowing).

? On-site: Brisbane presence for planning, design authority, showcases, cutovers, KT.



3. Metrics for long-term sustainability/effectiveness of capability uplift

? Delivery & quality (indicative): DORA (deployment frequency, lead time, change fail rate, MTTR), % automated tests/contract tests, % policy-as-code coverage.

? Platform operability ((indicative)) : SLO attainment, incident rate/trend, DR/RTO drill pass rate, % integrations with baseline observability.

? Adoption & autonomy: % work WCQ-led (design/build/test), reverse-shadow sign-offs, KT hours delivered vs planned

? Cost & efficiency: Forecast vs actual run-rate

4. Proficiency validation approach

? Gate-based evidence: WCQ engineers design and deploy unaided a representative API/event flow; pass runbook drills (incident triage, rollback, DR).

? Sign-off: Reverse-shadow to WCQ-led with named signatories (Platform Lead, Security, Release).



5. Cost management preferences (capacity vs consumption)

? Model-agnostic, but require transparent, separable pricing for licence/subscription, platform support, professional services.

? Forecasting & control: Budgets, alerts, soft/hard spend caps, quotas/rate limits, and monthly consumption reports by environment/domain/API/topic.

? Scenario pricing: Provide capacity-based and consumption-based scenarios with price deltas, including Non-Prod/Prod/DR and retention tiers.



6. Operating model

? Central platform (WCQ): Ingress/L7 LB/WAF, private networking, identity (Entra ID), certs/keys, global policies/templates, environment strategy, release governance, shared observability/FinOps.

? Domains (WCQ squads): Interface design & build (APIs/events/files) within guardrails, test ownership (functional/contract/NFR), operational runbooks for services they own.

? Governance: WCQ-chaired Design Authority; exceptions provided by respective Design Authority;



7. Responsibilities for edge components (LB/WAF/private networking)

? WCQ / Cloud and Infrastructure (own & operate): L7 load balancer/ingress, WAF, DDoS posture, private endpoints/links, private DNS, certificates/PKI, and network segmentation.

? Supplier / Platform provider: Integrate cleanly with WCQ edge; supply artefacts (reference architectures, limits), support mTLS/policy-as-code; no public endpoints by default.

? Run model: Changes at the edge follow WCQ change control; platform changes must not relax WCQ’s private-first stance.



Kind regards

Scott

Question:
Hello

What DevOps tooling is used by WCQ if any? Does WCQ have preference/standards around DevOps tooling expected to be used for the new integration platform?

Answered on 07/Apr/2026 10:38 AM:


Morning Simon,

In response to your clarification please see below:

The primary DevOps tools in use at WCQ are: GitHub (repository), Terraform (IaC), GitHub actions (deployment), however these tools are not mandated. Responses to FR-025 should describe the DevOps capability of the supplier in the context of the prompts provided.

Kind regards'

Scott McNeil

Question:
1 Does WCQ have a preferred MuleSoft runtime hosting model (CloudHub/CloudHub 2.0 versus on-premises or customer-managed runtime), and are there any mandatory constraints (e.g., data residency, network segmentation, or connectivity) that drive this preference?

2 We understand MuleSoft is intended to be the enterprise integration platform in the future state. Could you please outline the current integration platforms/tools and any event- or queue-based systems in use today?

3 WCQ has advised that all external exposure must occur via the WCQ API Gateway. Can you please tell us if MuleSoft would need to integrate with the existing enterprise API Gateway while ensuring required controls are maintained, including security policies, traffic management (e.g., throttling/rate limiting) and end-to-end observability.

4 Which external systems does WCQ currently integrate with as part of its operations?

Answered on 24/Mar/2026 09:29 AM:


Hi Sanmeet,

Thank you for your questions. Questions 1–3 assume the selection of MuleSoft as the preferred product. As the ITO does not nominate or pre-determine a specific platform, could you please rephrase these questions without that assumption so we can provide an accurate and complete response.

In response to Questions 4:

WCQ currently integrates with government and private organisations in fulfilment of various business processes. Most of these interactions are outbound requests to third parties to retrieve data as part of enrichment actions. A smaller number of endpoints exist to support inbound messages from partner organisations in order to streamline specific steps in the fulfilment of larger end-to-end processes.

Kind regards

Scott McNeil

Question:
Further questions for clarification:

What is the existing integration platform being used in WCQ? What's current volume can complexity incidents details per year? ( exmaple, Simple API Gateway , Complex integration , Sev 1, Sev2 and sev3 details). WCQ-672_Part_B_Statement_of_Requirements_Integration.pdf (Sec 1.7 and 5.2)

Regarding FR-033 (B2B/EDI) - How these interfaces are managed currently and what's the complexity of these core service interfaces in WCQ? WCQ672-Part_D-Attachment_1_Requirements_(Functional_&_Non-Functional)_Final.xls Regarding FR-033

Regarding FinOps / Observability FR-054. Are there any existing procuduct in WCQ used for FinOps/Objerveablity purpose ? (ie. Grafana, prometeus) WCQ672-Part_D-Attachment_1_Requirements_(Functional_&_Non-Functional)_Final.xls Regarding FR-054

Answered on 25/Mar/2026 04:21 PM:


Afternoon Aaron,

In response to clarification questions please see below.

1. WCQ does not currently have a formal integration platform but rather supports different application integration capabilities through standalone components including a simple API gateway for externally facing APIs. Refer to section 1.3 “Context and Strategic Alignment” for the motivation for a new integration platform.



2. The protocols defined in FR-033 refer to an expectation of the protocols that the integration platform could be required to support as part of a managed file transfer capability. A response to this requirement should describe how the proposed solution would do this either directly or indirectly. Current use of these protocols is limited to scheduled, outbound file exchange.



3. WCQ use a range of Cloud Finance Management tools. The response to FR-054 should explain what features of the integration platform can be used to monitor cost in the context of the consumption pricing.

Kind regards

Scott McNeil

Question:
We have a quick question regarding the NDA included as part of the tender documentation.

Given we already have existing contractual confidentiality arrangements in place under our current agreement with WCQ, could you please confirm whether it would be acceptable for us to rely on those existing provisions rather than executing the additional NDA document?

Our understanding is that the current agreement already provides the necessary coverage, so we wanted to check if formal acknowledgement of this would suffice.

Appreciate your guidance on this.

Answered on 26/Mar/2026 01:05 PM:


Hi Hemanth,

Thank you for your query.

On this occasion, the existing confidentiality provisions under the current WCQ agreement do not extend to this procurement activity. To ensure appropriate probity and to meet the requirements of the tender process, a new NDA must be executed specifically for this activity.

Please proceed with completing the NDA included in the tender documentation.

If you need any assistance, feel free to let me know.

Kind regards,

Scott McNeil

Question:
Can WCQ provide further detail on the specific systems and integration scope expected within TS1, including number of integrations and system interfaces?

Answered on 27/Mar/2026 02:31 PM:


Afternoon Aislinn,

The Transition State 1 (TS1) scope will involve a combination of current and target state applications. The iPaaS must be able to support any integration solution required for TS1 including but not limited to the exposure of current services as new APIs, intermediate data transformation, and different forms of data movement.



The specific systems associated with TS1 are still being identified. The number of integrations and system interfaces involved will not be known until these are finalised. If this question relates to “Scope of Work B – Professional Services”, please indicate how the number of integrations and system interfaces involved will affect a professional services engagement that is time-limited, clearly scoped and focused on enabling internal ownership and capability.

Kind regards

Scott McNeil

Question:
Does WCQ already own Splunk as a centralised logging and log analytics platform?

Answered on 30/Mar/2026 01:42 PM:


Hi Aislinn,

In reference to the use of Splunk. WCQ does not use Splunk as you have referenced nor own it.

Kind regards

Scott McNeil

Question:
Could you provide a high-level overview of your current integration landscape (high level architecture) — including the approximate number of integrations in place and the predominant patterns in use, such as RESTful APIs, batch or file-based transfers, point-to-point connections, or ETL processes?

Answered on 02/Apr/2026 03:23 PM:


Afternoon Shivi,

Recall from section 1.6 of Part B Statement of Requirements: “WCQ currently utilises a monolithic, highly customised central system CPIS which manages claims, policies, customer profiles etc.”. As a result, the majority of data movement is internal to that system, with exceptions that constitute the current integration landscape. These include:

• Numerous batch processing to execute ETL for reporting and analytics purposes (~50%)

• A number of internal services integration with external third-parties using a mix of REST APIs and managed file transfer (~10%)

• A limited number of inbound and externally facing REST APIs that are used by trusted partners and government agencies for submitting records

• A set of APIs supporting a custom mobile application



Kind regards

Scott McNeil

Question:
We'd appreciate some background on CPIS — Do you plan to integrate this as well ? if yes, how does CPIS expose its data (for e.g. REST API, direct database access, or file-based extracts)?

Answered on 01/Apr/2026 12:22 PM:


Afternoon Shivi,

The Claims and Policy Information System (CPIS) is a highly customised system that serves as the core application for WCQ and is used to manage claims, policies, customer profiles. Currently CPIS retrieves data from external third-parties through REST APIs and managed file transfer, and exposes a limited set of REST APIs to support application integration trusted partners.



The target state architecture of the 2030 strategy replaces CPIS with individual SaaS applications specific to each business domain. As a result, any integration with CPIS will ultimately be either migrated to or made obsolete by a corresponding SaaS application. However during transition, the integration platform will be required to deliver targeted, bespoke REST APIs for new services exposed by CPIS. As transition phases complete, corresponding transitional REST APIs will be decommissioned.

Kind regards

Scott McNeil

Question:
Are there existing middleware or ESB solutions that will need to be considered in scope — such as IBM MQ, BizTalk, Boomi, or a legacy MuleSoft 3.x instance? If so, has a decommissioning roadmap been defined for any of these?

Answered on 01/Apr/2026 12:24 PM:


Afternoon Shivi,

The integration platform is intended to operate as shared enterprise infrastructure, consumed selectively in accordance with approved integration patterns, and is independent of the limited middleware that exists outside of CPIS. Decommissioning of limited middleware is not in the scope of this proposal.

Kind regards

Scott McNeil

Question:
Is an API Gateway or API management solution currently in place? If so, which platform is in use, and how do you envision its role evolving in relation to the new integration platform?

Answered on 01/Apr/2026 12:31 PM:


Afternoon Shivi,

A small number of APIs are exposed through a tactical API gateway. These APIs will be migrated to the new integration platform when the underlying business function is moved from CPIS to the associated SaaS application. This tactical API gateway has no role with the new integration platform.

Kind regards

Scott McNeil

Question:
Are there on-premises systems that will require connectivity to the cloud environment? How many environments are involved, and are there any firewall or network constraints we should factor into the architecture early on?

Answered on 01/Apr/2026 04:38 PM:


Afternoon Shivi,

With respect to the integration platform, there are no systems on-premises that will require connectivity to the cloud environment. Recalling for section 1.4 that the integration must support selective integration between SaaS applications. The architecture of the integration platform assumes appropriate network security is available to protect endpoints and traffic from related risks. A response could recommend security controls in the context of the relevant functional requirements.

Kind regards

Scott McNeil

Question:
What is the total number integrations frequency and type of integrations (unidirectiona or bi-directional)?

Answered on 01/Apr/2026 04:39 PM:


Afternoon Shivi,

Refer to section 1.6 of the Part B Statement of Requirements Integration for indicative CPIS volumes between the 2nd and 20th of February 2026.

Kind regards

Scott McNeil

Question:
Please specify the average request volumes, frequency, and spike volumes for the critical APIs?

Answered on 07/Apr/2026 10:19 AM:


Morning Shivi,

In response to your question WCQ provide the following response:

The average request volumes for critical APIs are low where most requests these occur at specific times corresponding to the business process of the external participants, e.g. employer pay runs. Even during these spikes the number of requests are in the order of 1000s.



Kind regards

Scott McNeil

Question:
Do you want to leverage existing API gateway or use MuleSoft provided API gateway ?

Answered on 01/Apr/2026 04:31 PM:


Afternoon Shivi,

WCQ is seeking to procure an enterprise Integration Platform as a Service (iPaaS) to establish a consistent, secure and scalable integration capability that can be consumed across the organisation. Although a tactical gateway exists and supports a small number of REST APIs it will not be part of the transitional or target architecture and will not be leveraged once the new integration platform is implemented.

The purpose of this procurement is to obtain an integration platform for WCQ that best satisfies the requirements outlined in Part B – Statement of Requirements and the supporting schedules. It does not presuppose the outcome of the procurement process.

Kind regards

Scott McNeil

Question:
What authentication standards are required — OAuth 2.0, mTLS, JWT? And which identity provider is in use — Azure AD, Okta or something else?

Answered on 01/Apr/2026 04:32 PM:


Afternoon Shivi,

FR-005 asks the supplier to explain which of the authentication and authorisation methods listed are supported by the integration platform. It should be assumed that whatever IAM service is available to the integration platform, it will support the methods shown.

Kind regards

Scott McNeil

Question:
Is QLD already using any event broker (Kafka, Azure Event Hub, and RabbitMQ)?

Answered on 01/Apr/2026 04:34 PM:


Afternoon Shivi,

FR-035 ‘Complex Event Processing’ asks the supplier to describe the processing capabilities of the event streaming service of the integration platform they are proposing, independent of which one, if any, is currently in use at WCQ.

Kind regards

Scott McNeil

Question:
Are bulk data migrations or ETL-style workloads expected as part of this scope?

Answered on 01/Apr/2026 04:36 PM:


Afternoon Shivi,


Bulk data migrations or ETL-style workloads are considered a ‘Bronze’ pattern and so are not explicitly part of the scope of these requirements. Regardless, if the proposed integration platform does not support this style of data integration, then along with any others it should be noted explicitly in response to FR-052 ‘Catalog & Governance’.

Kind regards

Scott McNeil

Question:
What are the compliance requirements for PII, PHI, masking and tokenisation?

Answered on 02/Apr/2026 03:30 PM:


Hi Shivi

WCQ is subject to the Queensland Information Privacy Act 2009 and its interpretation in the Queensland Privacy Principles. As well as the requirements and mandatory questions under the issued ITO.

Kind regards

Scott McNeil

Question:
Which observability, monitoring, logging tools are currently in use — Splunk, Datadog, Azure Monitor? Should MuleSoft push metrics and logs into those platforms?

Answered on 01/Apr/2026 04:37 PM:


Afternoon Shivi,

WCQ currently use an enterprise observability tool however it is being evaluated for alignment with the 2030 strategy. The main functional requirements relating to observability on the integration platform are defined by FR-028 and FR-045 and are not specific to a particular enterprise observability tool.

Kind regards

Scott McNeil

Question:
Please describe your current CI/CD tooling and release strategy.

Answered on 02/Apr/2026 03:21 PM:


Hi Shivi,

The primary CI/CD tools in use at WCQ are: GitHub (repository), Terraform (IaC), GitHub actions (deployment), however these tools are not mandated. Responses to FR-025 should describe the DevOps capability of the supplier in the context of the prompts provided.

The WCQ release strategy operates at two levels: standard changes for a pre-approved, low-risk change that follows an established and repeatable procedure; normal changes that require review and approval by a Service Offering group and optionally for moderate to high risk changes subsequent review and approval by a change advisory board.

Kind regards

Scott McNeil

Question:
What is the coverage and expected timelines for TS1

Answered on 07/Apr/2026 10:44 AM:


Morning Shivi,

In response to your clarification please see the below:


The Transition State 1 (TS1) scope will involve a combination of current and target state applications. The iPaaS must be able to support any integration solution required for TS1 including but not limited to the exposure of current services as new APIs, intermediate data transformation, and different forms of data movement.



The specific systems associated with TS1 are still being identified. The number of integrations and system interfaces involved will not be known until these are finalised. If this question relates to “Scope of Work B – Professional Services”, please indicate how the number of integrations and system interfaces involved will affect a professional services engagement that is time-limited, clearly scoped and focused on enabling internal ownership and capability.

Kind regards

Scott McNeil

Question:
Could you please respond to this below question?

As part of our preparation for the iPaaS tender, our legal team has commenced a review of the NDA included in the tender documentation. During this review, certain provisions have been identified that require clarification and/or potential adjustment to enable internal approvals for execution.

We acknowledge the requirement to execute the NDA as a condition of submission and are approaching this in good faith with the intention of meeting this obligation.

Could you please advise whether the procurement process allows suppliers to submit a marked-up version of the NDA with proposed amendments for consideration alongside our response.

Answered on 01/Apr/2026 09:29 AM:


Morning Hemanth,

In this instance we will not be accepting a marked up version of the NDA. If you wish to share or have departures to that document please added it to the Contract Departures register that was supplied for consideration and review.

Kind regards

Scott McNeil

Question:
Hi Scott,

quick question on 'NFR 16: The platform must be provided as a software-as-a-service (SaaS) encompassing all aspects of support and management.'

Question: Does the required support and management for NFR 16 specifically refer to platform support or managed services support from SIP?

Answered on 08/Apr/2026 08:38 AM:


Morning Grace,

In response to your question please find the following:

The requirement states that the ”platform must be provided as a software-as-a-service (SaaS) encompassing all aspects of support and management” and does not make a distinction between support for the “platform” and “managed services”.

If the respondent believes a distinction exists and this is relevant to support of the integration platform as a SaaS offering then in each case they should follow the guidance from the “Clarifying Question/Prompt” column for NFR-16 and respond accordingly.

Kind regards

Scott McNeil

Question:
I would like to seek clarification regarding the Supplier Execution of Offer – Acknowledgements and Certifications section of the Part D response form.

As this section requires formal acceptance and execution alongside the submission of our offer, could you please confirm whether suppliers are permitted to propose minor amendments to this section (for example, limited to wording clarifications or alignment with our standard contractual requirements)?

Additionally, if such minor changes are proposed, would our response still be considered compliant, or would any deviation from the prescribed wording impact compliance? We appreciate your guidance on this to ensure our submission aligns fully with the tender requirements.

Answered on 01/Apr/2026 04:27 PM:


Afternoon Hemanth,

Thank you for your query regarding the Supplier Execution of Offer – Acknowledgements and Certifications section (Part D) of the response form.

Part D forms a key component of the response schedule and is designed to ensure that all suppliers provide the required acknowledgements and certifications in a consistent format, in line with the ITO requirements. As such, it must be completed and submitted without amendment.

Any changes to the wording, including minor clarifications or alignment to standard contractual positions, would result in the response not meeting the prescribed format and therefore being deemed non-conforming. The only change is catered for with any departures to the QITC contract, where WCQ has provided a Contract Departures register to be used for that benefit that requires to be submitted as part of Section 5 Supplier Checklist in the Response Form, PART D.

To ensure compliance, suppliers are required to accept and execute this section exactly as provided.

Kind regards

Scott McNeil

Question:
Regarding FR-016 (Managed Runtime Lifecycle) and the requirement for secure hybrid connectivity: If the proposed iPaaS architecture utilises lightweight, customer-hosted runtime agents within WCQ's private network to execute integrations, does WCQ expect the vendor to estimate the underlying cloud infrastructure compute costs (e.g., AWS EC2/EKS instances) within the Table A pricing submission? Or should Table A strictly reflect the vendor's software licensing, support, and control plane costs, with the assumption that WCQ will absorb the local IaaS compute costs for those specific nodes?

Answered on 07/Apr/2026 01:55 PM:


Afternoon Hitesh,

In response to your clarification please see the below:

Table A should reflect supplier licensing, support and control-plane charges.

• For customer-hosted runtime agents, WCQ will generally absorb the underlying IaaS compute costs where those nodes are provisioned and paid for directly by WCQ.

• Suppliers must still provide an indicative sizing and compute cost estimate (clearly marked as WCQ-paid, non-binding) to enable total cost and operability assessment.



Kind regards

Scott McNeil

Question:
Regarding the requirement to support a domain-based operating model (NFR-022) and the request to price Shared vs. Dedicated Infrastructure (Table C): Does WCQ consider strict logical isolation such as separate virtual private clouds, dedicated environment namespaces, and rigorous Role-Based Access Control (RBAC) sufficient to meet the "Dedicated/isolated" pricing tier for individual domain squads? Or does WCQ mandate physically separated underlying compute nodes (e.g., single-tenant messaging brokers or API gateways) to satisfy cross-domain isolation?

Answered on 08/Apr/2026 08:37 AM:


Morning Hitesh,

In response to your question please find the following:

Please show how the proposed solution satisfies the requirements defined by NFR-022. If these requirements can be satisfied in different ways the respondent can choose to define one or all of these with sufficient detail across other areas of the proposal, like platform costs, to enable WCQ to evaluate these clearly.

However, please in your response make this clear.



Kind regards

Scott McNeil

Question:
Regarding the Scope B Professional Services pricing and the platform-led mandate clarified in Addendum 2: Given that the exact number of TS1 system interfaces is not yet finalised, is it acceptable to provide a fixed-price "Platform Establishment and Enablement Foundation" package, supplemented by a transparent rate card and a capped Time & Materials (T&M) estimate for the variable TS1 integration build and pairing activities?

Answered on 08/Apr/2026 08:41 AM:


Morning Hitesh,

In response to your question please find the following:

This is not acceptable. With reference to the “Pricing Requirements” section of Part B Statement of Requirements:

• Separate pricing for Scope A and Scope B is explicitly requested: “Suppliers are required to price Scope A – Integration Platform (iPaaS) and Scope B – Professional Services as separate components.”

• Fixed pricing is explicitly defined as non-aligned: “Pricing models that rely on fixed capacity assumptions, obscure consumption drivers, or bundle services in a way that limits transparency or flexibility will not be considered aligned to WCQ’s requirements”.

If there is any change made to the pricing model supplied under the ITO, the bid may be determined as non-conforming.

Kind regards

Scott McNeil

Question:
During Transition State 1 (TS1), the iPaaS will deliver targeted, bespoke REST APIs to interface with the legacy CPIS system. Are there any specific latency constraints, legacy protocol translations, or direct database access requirements for CPIS that would necessitate deploying a self-hosted integration runtime (agent) directly within WCQ’s network? Or is secure cloud-to-ground connectivity (via IPsec VPN or direct links) to a fully vendor-hosted cloud runtime sufficient?

Answered on 08/Apr/2026 08:42 AM:


Morning Hitesh,

In response to your question please find the following:

Specific latency constraints, legacy protocol translations, or direct database access requirements for CPIS have not been defined that would necessitate deploying a self-hosted integration runtime (agent) directly within WCQ’s network.

However that does not preclude this configuration being applied during TS1 if it was considered appropriate to resolve discovered limitations of this kind or to optimise interactions between the API gateway and other resources.



Kind regards

Scott McNeil

Question:
WCQ requires that all production customer data, operational telemetry, backups, and DR replicas remain within Australian data centres. Does this strict data residency requirement preclude the use of global control-plane routing for metadata (such as global identity federation, platform login routing, or global API catalog search functionality), provided that all actual message payloads, runtime deployments, and execution logs remain strictly onshore?

Answered on 08/Apr/2026 09:43 AM:


Dear Hitesh,



In response to your questions see the following response:



WCQ’s data sovereignty requirements apply specifically to services that store or process PII or sensitive information. For components that do not handle such data, offshore hosting may be acceptable.

However, WCQ still considers the operational risks associated with offshore services—such as reduced control, dependency on foreign jurisdictions, and potential impacts on service continuity.



These risks will be assessed as part of the evaluation based on the detail and quality of your proposed approach.



If you believe an offshore component is appropriate, please outline the rationale and the controls you will implement to mitigate any associated risks.



However, please consider the following in your repose to the ITO:



Information Privacy Act 2009 - Queensland Legislation - Queensland Government

Guidelines - Privacy principles | Office of the Information Commissioner Queensland



Kind regards



Scott McNeil

Question:
WCQ mandates a private-only ingress by default with explicit exceptions for external-facing APIs. To ensure a seamless zero-trust architecture between WCQ’s edge and the iPaaS, will WCQ’s L7 load balancer terminate external TLS and route traffic directly to the iPaaS private endpoints (e.g., via AWS PrivateLink)? Or is the iPaaS provider expected to supply and manage a dedicated ingress controller/load balancer within the platform's isolated cloud boundary to handle internal certificate management, SNI, and routing?

Answered on 08/Apr/2026 08:43 AM:


Morning Hitesh,

In response to your question please find the following:

WCQ’s L7 load balancer will terminate external TLS and route traffic directly to the iPaaS private endpoints.

Kind regards

Scott McNeil

Question:
1. Does WCQ have a preferred deployment or hosting model for its integration runtime (such as cloud-hosted versus on-premises/customer-managed), and are there any mandatory requirements—such as data residency, network segmentation, or connectivity considerations—that influence this preference?

2. We understand that an enterprise-wide integration platform is planned for the future state. Could you please describe the integration platforms, tools, and any event-driven or message-queue–based systems currently in use across the organization?

3. WCQ has indicated that all external exposure must go through the enterprise API Gateway. Could you confirm whether the new integration platform will need to interoperate with the existing API Gateway, while ensuring the necessary controls—such as security policies, traffic management (e.g., rate limiting), and end-to-end observability—are maintained?

4. From Part B perspective, to help us align our proposal, could you share more detail on the key roles and expertise, WCQ expect the vendor to provide

5. Can WCQ confirm the target cloud provider for iPaaS runtime deployment (Azure / AWS) and whether Australian data residency is required for all environments or Prod/DR only?

6. What Production high-availability model is expected (multi-AZ, active-active, active-passive), and what Disaster Recovery approach is required (hot/warm/cold), including whether DR applies only to Prod or all environments?

7. How many environment stages are expected (e.g., Dev, Test, UAT, Prod, DR), and what is the standard promotion path between them?

8. What is the approximate number of APIs expected in TS1, the anticipated growth trajectory, and are there any known priority integrations planned for the initial phase?

9. What DevOps toolchain is currently standard at WCQ (version control, CI/CD platform, IaC tools such as Terraform/ARM)?

10. Is WCQ expecting reuse of existing CI/CD platforms, or is adoption of platform-recommended pipelines acceptable, and are security scans (SAST/DAST, dependency scanning) mandatory within pipelines?

11. Is there an enterprise monitoring / SIEM tool (e.g., Splunk, Sentinel, Dynatrace) that iPaaS runtimes and CI/CD pipelines must integrate with?

Post-enablement, who will own CI/CD pipelines (WCQ teams vs supplier), and what support coverage is expected for platform and DevOps (8×5, 16×5, 24×7 Prod-only), including any on-call expectations after TS1?

Answered on 07/Apr/2026 01:52 PM:


Afternoon Sanmeet,

In response to your 11 clarification questions please find the following:

1. The deployment or hosting model for the integration runtime should be appropriate for the proposed integration platform and align with the requirements as specified in the RFP.



2. WCQ currently utilise a monolithic, highly customised central system CPIS which manages claims, policies, customer profiles. No formal integration platform or supporting tools and systems exist as there has not been a requirement for one to exist. Some integration capabilities exist but these are not relevant to the new enterprise-wide integration platform. A response to this procurement request should describe any tools, and any event driven or message queue–based systems relevant to the proposal

3. The new integration platform will not need to interoperate with the existing Gateway



4. The scope of Work B defines the nature of the professional services required by WCQ and how these will work alongside WCQ resources. It does not define roles or expertise so that the respondent can offer an appropriate combination of resources to deliver these services



5. WCQ is currently agnostic to the cloud provider for the iPaaS runtime. Regarding ‘Australian data residency’, WCQ is subject to the Queensland Information Privacy Act 2009 and its interpretation in the Queensland Privacy Principles.



6. NFR3 asks for details on the platform availability. If is relevant to the response, the respondent will describe the high-availability model and the disaster recovery approach associated their proposal.



7. Analysis of the preferred environments is ongoing



8. The priority of integrations for TS1 will be determined by the requirements of applications selected for the 2030 strategy during this transitional period. As this process is still on-going, the types and priority of integration is unclear. Preliminary analysis highlights data synchronisation between CPIS and new applications to be an important type of integration for TS1.



9. The primary CI/CD tools in use at WCQ are: GitHub (repository), Terraform (IaC), GitHub actions (deployment), however these tools are not mandated. Responses to FR-025 should describe the DevOps capability of the supplier in the context of the prompts provided.



10. As per the response to question (9) above, the existing DevOps toolchain is not mandated. The respondent should explain the motivation for adopting any platform recommended pipelines.



11. WCQ currently uses an enterprise observability tool however it is being evaluated for alignment with the 2030 strategy. The main functional requirements relating to observability on the integration platform are defined by FR-028 and FR-045 and are not specific to a particular enterprise observability tool.



12. Please refer to the section “EC2 - Platform support and knowledge transfer” of the Part B Statement of Requirements with emphasis on the following:

- “WCQ requires an integration platform offering that can be operated reliably, securely and sustainably as part of business-as-usual operations”

- “Specific service level thresholds are not mandated. However, suppliers are required to provide sufficient detail to allow WCQ to assess the maturity, robustness and suitability of the proposed platform support and operational arrangements”

Kind regards

Scott McNeil

Question:
Additional questions from Cognizant.

1. Are there any known priority integrations planned for TS1?

2. What DevOps toolchain is currently standard at WCQ?

3. Version Control, CI/CD platform, IaC tool (Terraform / ARM / other)

4. Is DevOps support expected only during TS1 enablement, or as part of ongoing BAU?

Answered on 07/Apr/2026 10:15 AM:


Morning Sanmeet,

Clarification of the Questions you have asked please see below:


1. The priority of integrations for will be determined by the requirements of applications selected for the 2030 strategy during this transitional period. As this process is still on-going, the types and priority of integration is unclear. Preliminary analysis highlights data synchronisation between CPIS and new applications to be an important type of integration for TS1.



2/3. The primary CI/CD tools in use at WCQ are: GitHub (repository), Terraform (IaC), GitHub actions (deployment), however these tools are not mandated. Responses to FR-025 should describe the DevOps capability of the supplier in the context of the prompts provided.



4. DevOps support is part of ongoing BAU.



Kind regards

Scott McNeil