Enterprise Managed Service Provider Tender Template & Guide

[Organisation] invites proposals for the provision of enterprise cloud, infrastructure and managed services to support its current and future technology environment.

The procurement seeks a provider capable of delivering secure, resilient and scalable services together with ongoing operational management, transparent governance, predictable commercial arrangements and an orderly transition into and out of the service.

The successful solution should, where applicable:

• replace or reduce dependency on ageing customer-owned infrastructure;
• improve resilience, recoverability and security maturity;
• provide flexible access to compute, storage, network and managed-service capacity;
• reduce lifecycle and supply-chain risk;
• provide clear operational accountability and escalation;
• support future growth without repeated major procurements;
• provide transparent costs and minimise unexpected professional-services charges; and
• preserve practical portability and exit options throughout the contract term.

Bidders must respond to each mandatory and desirable requirement using the response schedules provided. Any qualification, dependency, assumption or exclusion must be stated explicitly.

Where a bidder relies upon a related entity, subcontractor, hyperscale cloud platform, carrier, software vendor or other third party, that dependency must be identified.

[Organisation] identifies the procurement method, governing rules and any prequalification scheme, panel or standing offer under which this process is conducted.

Bidders confirm eligibility to participate and, where a prequalification scheme applies, state their registration status, tier and registration identifier. For example, under the NSW SCM0020 Prequalification Scheme: ICT Services, bidders identify whether they are a Registered or Advanced Supplier.

[Organisation] provides a concise profile covering business functions, user population, operating hours, critical services, regulated activities, geographic footprint and expected growth.

[Organisation] provides a current-state summary and appends detailed schedules (see Appendix A) covering:

• sites and locations;
• users and identity platforms;
• physical and virtual servers;
• virtualisation technologies and versions;
• operating systems and application platforms;
• storage capacity, performance and growth;
• network and internet connectivity;
• firewalls, VPN and remote access;
• backup, retention and archive;
• disaster recovery arrangements;
• monitoring and security tooling;
• licensing and vendor dependencies; and
• known end-of-life or capacity risks.

Bidders complete the workload schedule (Appendix B) identifying business owner, application dependency, data sensitivity, recovery priority, target RPO, target RTO, maintenance constraints and supported technology requirements for each material workload.

Bidders address all applicable services, including design, compute, storage, networking, connectivity, security, backup, disaster recovery, monitoring, service management, transition, ongoing management, reporting, professional services and exit assistance.

[Organisation] identifies application ownership, end-user computing, business application support, software development and other functions that remain outside scope unless proposed as optional services.

Bidders may propose alternative architectures where they can demonstrate improved security, resilience, operability or whole-of-life value. Alternatives must be clearly separated from the conforming response and must identify all material assumptions and dependencies.

Bidders provide a logical and physical architecture description showing service boundaries, availability zones or failure domains, network flows, management planes, backup paths, recovery dependencies, security controls and third-party services.

Bidders provide a detailed responsibility matrix (RACI, Appendix K) covering infrastructure, hypervisor or cloud layer, operating systems, databases, applications, identity, backups, security controls, patching, monitoring, incident response, certificates, firewalls and recovery testing.

Bidders describe how the proposed solution supports organic growth, temporary demand, acquisitions, new sites, additional workloads and technology refresh without requiring a complete redesign or new procurement.

Bidders provide a catalogue and unit pricing for generic resources, including vCPU, memory, standard and high-performance storage, backup capacity, public IP addresses, bandwidth, load balancing and other commonly consumed services. Identify minimum increments and any minimum commitments.

Bidders describe resource allocation, performance management and contention controls, including how CPU, memory, storage and network performance are protected during periods of high utilisation. Identify any relevant fair-use, burst or throttling policies.

Bidders identify supported virtualisation formats, operating systems, CPU architectures, guest tools, clustering technologies and any workload classes that require dedicated or specialised infrastructure.

Bidders describe capacity monitoring, growth forecasting, alert thresholds and the process for adding capacity before service risk emerges.

Bidders describe available storage classes, performance characteristics, resilience model, snapshots, replication, encryption, capacity increments and applicable limits. State how performance is measured and governed.

Bidders describe supported methods for bulk import and export of data, including online transfer, physical transfer where available, bandwidth options, expected timeframes, formats and charges.

Bidders identify whether snapshots and replicas are crash-consistent or application-consistent, their failure-domain separation, retention limits and whether they are independently protected from privileged compromise of the production environment.

Bidders describe capabilities for internet, private WAN, SD-WAN, VPN, direct connectivity, cross-connects, carrier services, BGP, public IP addressing, IPv6, DDoS protection and remote-site connectivity where applicable.

As part of transition, bidders review the existing connectivity estate and recommend opportunities to improve resilience, reduce unnecessary services, simplify routing or consolidate cost. Recommendations must preserve required diversity and business continuity.

Bidders identify carrier, path, facility, power and equipment diversity for each critical connectivity service. Where true physical diversity cannot be confirmed, this must be stated explicitly.

Bidders define who diagnoses and coordinates incidents that span the provider platform, carrier network, customer site, firewall and third-party services. Identify escalation paths and after-hours arrangements.

Bidders describe the information security management framework governing the proposed services, including risk management, policies, control ownership, incident management, internal review, external assurance and continual improvement.

Where certifications are claimed, bidders identify the certification body, current certificate, scope statement, expiry or surveillance status, and exactly which proposed services, locations and operational functions fall within scope. Material exclusions must be identified.

Bidders provide relevant independent assurance evidence. This may include ISO/IEC 27001 certification, PCI DSS validation where applicable, penetration testing, external audit or other evidence appropriate to the proposed service. State the scope and date of each assurance activity.

Bidders describe physical security, datacentre access control, visitor management, asset handling, secure disposal, media handling, infrastructure administration and separation of customer and management environments.

Bidders describe encryption in transit and at rest, key management, MFA, privileged access, role-based access control, administrative segmentation, firewalling, secure remote access, logging, vulnerability management, endpoint protection and configuration hardening.

Bidders provide patch and vulnerability management processes for all layers within provider responsibility, including hypervisors, operating systems, network devices, storage systems, firmware, management platforms and security appliances.

State standard and emergency remediation targets, exception governance, customer notification requirements and how unsupported software is handled.

Bidders describe recurring security governance included within the service, such as risk review, security metrics, patch compliance, vulnerability trends, incident review, control exceptions, improvement actions and executive reporting. State the proposed cadence and attendees.

Bidders complete the Security Service Inclusion Schedule (Appendix C), identifying for each activity whether it is included in recurring charges, subject to a usage allowance, provided at time-and-materials rates, or excluded.

Bidders describe all material sovereignty characteristics and overseas dependencies of the proposed service, including data storage, backups, disaster recovery, logs, telemetry, support systems, monitoring, privileged administration, security operations, AI-assisted services, subcontractors, legal entities and critical technology dependencies.

For each material component, identify the country or countries involved, the responsible legal entity, the nature of access or processing, and whether the arrangement may change during the contract term. Responses are recorded in the Sovereignty and Subprocessor Schedule (Appendix F).

Bidders state whether countries, subcontractors, support locations, AI services, monitoring platforms or privileged-access arrangements may change during the contract. Material changes must be notified in advance and, for defined high-risk changes, be subject to [Organisation] approval or an agreed right to exit.

Bidders identify material service dependencies that could be affected by foreign sanctions, export controls, encryption restrictions, AI capability restrictions, trade disputes, tariffs, taxation changes, currency exposure or termination of an upstream technology service. Describe available mitigations and substitution options.

Bidders identify whether any customer data, metadata, logs, backups, support tickets, diagnostic exports, screen-sharing sessions, monitoring data or AI/automation outputs may be accessed, processed, viewed or stored by personnel or systems outside the customer-approved locations.

Identify all relevant countries, legal entities and subprocessors; the purpose and nature of access; access controls; logging; contractual protections; audit rights; breach notification; and the mechanism by which changes are notified and approved.

Bidders describe controls applying to employees, contractors and subcontractors with access to customer environments or information, including screening (e.g. police checks, and Australian Government security clearances where relevant), confidentiality, least privilege, MFA, privileged access management, session controls, monitoring, data-loss prevention, disciplinary processes and termination of access.

For designated high-sensitivity services, no offshore personnel access, offshore processing or new offshore subprocessor shall be introduced without prior written approval from [Organisation].

Bidders describe the backup and cyber-recovery service, including coverage, frequency, retention, immutability, encryption, administrative separation, failure-domain separation, monitoring, restore methods, recovery testing, reporting and charges. Detailed responses are recorded in the Backup and Recovery Schedule (Appendix E).

For each workload class, bidders state achievable RPO and RTO assumptions and identify dependencies that may prevent those objectives from being met. Distinguish backup completion objectives from service recovery objectives.

Bidders describe how backup copies are protected from compromise of production credentials, privileged administrators, ransomware and malicious deletion. Identify any separate identity, account, tenant, platform or administrative boundary.

Bidders state the frequency, scope and method of restore testing included in recurring charges. Testing should include representative file, application and full-system recovery where applicable, with documented outcomes and remediation of failures.

Bidders describe the ability to export backup data or recovered workloads to another environment, including formats, tooling, transfer rates and charges.

Bidders describe disaster recovery architecture, geographic and failure-domain separation, replication, failover, failback, orchestration, recovery sequencing, dependency management, testing and governance.

Bidders state the number and scope of DR tests included per year, expected customer participation, whether tests are disruptive, how findings are tracked, and whether retesting after remediation is included.

Bidders describe support for partial workload failover, isolated recovery environments and recovery from cyber incidents where production credentials or management systems may be untrusted.

Bidders describe the resilience model, redundancy, failure domains, hardware lifecycle strategy, refresh approach, firmware management, critical spare-parts strategy, component replacement process and restoration targets for infrastructure supporting the service.

Bidders identify which classes of critical spares are held by the provider, where they are held, expected access time, who performs replacement, after-hours capability, and which failures depend on OEM or third-party dispatch.

Bidders state normal refresh cycles, handling of end-of-life equipment, capacity refresh, migration responsibility, secure disposal and whether lifecycle replacement is included in recurring charges.

Bidders identify N+1 or other redundancy assumptions, automatic failover behaviour, maintenance without outage, storage protection, network redundancy and any single points of failure.

Bidders describe the service desk, NOC/SOC where applicable, hours of coverage, major-incident management, escalation tiers, direct access to infrastructure engineers, after-hours arrangements, subcontractors and vendor escalation paths.

Bidders provide proposed priority definitions, acknowledgement targets, technical engagement targets, update frequency, restoration targets and escalation triggers. Distinguish response from restoration.

Bidders describe standard, normal and emergency change processes; approval; maintenance windows; rollback; customer communication; and which routine changes are included within recurring charges.

Bidders describe root-cause analysis, recurring-incident review, corrective action tracking and post-incident reporting for material events.

Bidders describe monitoring, alerting, capacity management, service reporting, governance meetings and continuous-improvement activities included in the service.

Monthly or agreed periodic reporting should include, as applicable: availability, incidents, SLA performance, capacity, growth, backup success and restore testing, patch compliance, vulnerability status, security events, changes, risks, lifecycle issues, cost trends and improvement actions.

Bidders provide operational service reviews at an agreed cadence and executive or strategic reviews at least [quarterly / biannually]. Maintain an action register with owners and due dates.

At least annually, bidders provide an infrastructure health assessment and forward roadmap covering capacity, lifecycle, security, resilience, cost optimisation, technical debt and material improvement opportunities.

For each managed platform layer, bidders define supported versions, onboarding standards, patching, monitoring, backup integration, configuration management, vulnerability remediation, escalation and end-of-support treatment.

Bidders provide supported technology matrices for operating systems, databases, web platforms, containers, directory services and other managed components offered.

Bidders complete the RACI schedule (Appendix K) for operating systems, middleware, databases, applications, agents, certificates, backups, monitoring, vulnerability remediation and configuration changes.

Bidders provide a transition plan covering discovery, dependency mapping, design validation, connectivity, build, data migration, workload migration, testing, change control, rollback, coexistence, cutover, hypercare, documentation and handover. Milestones are recorded in the Transition and Acceptance Schedule (Appendix L).

Bidders state all assumptions regarding customer effort, application vendor involvement, downtime, data-transfer rates, licensing, unsupported systems, third-party approvals and remediation required before migration.

Bidders propose objective acceptance criteria for each transition stage, including performance, monitoring, backup, restore, security, connectivity, documentation and operational handover.

Bidders provide rollback criteria, decision authority, maximum rollback window and treatment of data divergence for material migrations.

Bidders provide complete pricing using the Pricing Schedule (Appendix H). Clearly distinguish recurring charges, usage charges, minimum commitments, implementation costs, licences, support, professional services, third-party charges, taxes (including GST treatment), indexation, data transfer, egress and exit charges.

Bidders complete a Service Inclusion Schedule that classifies each recurring operational activity as: Included; Included subject to stated allowance; Time and Materials; Project Quote; or Excluded.

Bidders provide time-and-materials rates by role, after-hours multipliers, minimum charge increments and any annual rate adjustment mechanism. Rates should also apply to optional transition and exit assistance unless otherwise stated.

Bidders provide unit prices for common compute, storage, backup, connectivity and managed-service increments to support growth and downsizing during the term.

Bidders provide a [3 / 5]-year total-cost model using stated assumptions, including implementation, recurring services, forecast growth, licences, bandwidth, backup, support, professional-services allowances and exit costs.

The proposed solution must support practical portability of customer workloads and data throughout the contract term and on exit.

Bidders describe supported export formats and procedures for virtual machines, disks, files, object data, databases, backups, configuration data, firewall and network configuration, logs and other customer-owned information.

Identify all proprietary dependencies that could materially increase the cost, complexity or time required to migrate to another provider or to customer-operated infrastructure. Detailed responses are recorded in the Portability and Exit Schedule (Appendix G).

Bidders state the ability to export virtual machines and disks on demand in commonly supported or documented formats. Identify supported formats, snapshot consistency, expected export time, self-service capability, bandwidth constraints and charges.

Bidders describe online and offline bulk export options, standard protocols and APIs, physical transfer options where available, expected throughput, charges and any provider-imposed egress limits.

On request and on exit, bidders provide current documentation and exportable customer-specific configuration reasonably required for transition, including architecture, IP addressing, firewall rules, VPN configuration, DNS dependencies, backup policy, monitoring configuration, asset inventory, open risks and operational procedures, subject to legitimate provider intellectual-property protections.

Bidders provide transition and handover assistance at pre-agreed time-and-materials rates unless included in the service. Assistance should be available to the customer and its nominated replacement provider, subject to reasonable security controls.

Bidders identify any customer data, workload or configuration that cannot be exported without proprietary provider tooling or conversion. State conversion methods, costs and expected timeframes.

Bidders disclose all charges that may apply to termination, data export, egress, media, engineering, early termination, licence conversion and decommissioning. Charges not disclosed in the tender response should not be introduced solely because the customer is exiting.

After verified transition and customer authorisation, bidders securely delete residual customer data in accordance with the agreed retention and destruction process and provide confirmation of completion, subject to lawful retention obligations.

Bidders provide service-specific availability commitments, measurement points, calculation methodology, exclusions, planned-maintenance treatment, reporting and service credits.

Bidders provide targets for acknowledgement, technical engagement, update frequency and restoration by priority. Define clock start/stop conditions and customer dependency treatment.

Bidders describe standard maintenance windows, notice periods, emergency maintenance, customer veto or deferral rules, and whether the architecture supports maintenance without customer-visible outage.

Bidders provide reasonable access to relevant assurance evidence and support customer audits subject to confidentiality, security and proportionality. State charges, if any, for routine evidence versus bespoke audit assistance.

Bidders provide evidence of organisational capability, including ownership, financial standing, years of operation, relevant customer experience, engineering capability, support locations, certifications, insurance, critical subcontractors and reference customers.

Bidders describe the roles and locations of personnel who will design, operate, support and secure the service. Identify use of subcontractors and the escalation path to senior engineering.

Bidders support material claims with evidence where reasonably available, such as certification scope, audit evidence, measured service performance, sample reports, recovery-test outputs, references or demonstrations.

Bidders describe the provider's own business continuity arrangements, key-person resilience, operational succession, remote-work capability, supply-chain resilience and ability to continue support during facility or regional disruption.

Bidders complete the following schedules in addition to the narrative proposal:

• Requirement compliance matrix;
• Solution architecture and dependency schedule;
• Service responsibility / RACI matrix;
• Security assurance and certification scope schedule;
• Security service inclusion schedule;
• Sovereignty, country and subprocessor schedule;
• Backup and recovery schedule;
• SLA schedule;
• Transition and migration schedule;
• Pricing schedule;
• Generic resource catalogue;
• Vendor lock-in and portability schedule; and
• Exceptions, assumptions and exclusions schedule.

Evaluation should consider whole-of-life value, evidence quality, material exceptions, operational dependencies, transition risk and exit cost. Where appropriate, [Organisation] reserves the right to conduct clarification workshops, technical demonstrations, reference checks and due diligence before final award.