SITA's PCT 1115 cloud framework.
SITA's PCT 1115 transversal framework was established to give national and provincial departments a pre-procured route to cloud services. The framework is not a vendor list. It is a structured procurement vehicle with multiple cloud categories, multiple awarded service providers, and a defined call-off process. The structure is more sophisticated than most procurement officers using it for the first time realise. A checklist for evaluating cloud proposals under the framework follows.
1. What PCT 1115 actually is
PCT 1115 is a transversal contract awarded by SITA on behalf of the national, provincial, and some local government markets. The contract pre-procures cloud services from a set of awarded service providers across multiple cloud categories. Departments needing cloud services can call off against the framework rather than running their own full procurement event.
The framework reduces the procurement effort for individual departments but does not eliminate it. The department still needs to specify what it is buying, evaluate the awarded providers against the specific need, and structure a call-off agreement that holds up.
The framework is also not infinitely flexible. The contract terms, the rate cards, the service-level structure, and the eligible cloud categories are defined by the original PCT 1115 award. Departments work within these constraints rather than negotiating them.
2. The four cloud categories
PCT 1115 covers four broad categories: infrastructure-as-a-service (compute, storage, networking on-demand), platform-as-a-service (managed databases, application platforms, container services), software-as-a-service (defined software products delivered as a service), and managed cloud services (the provider takes operational responsibility for the cloud environment on behalf of the department).
The categories are not interchangeable. A department buying IaaS gets resources and an empty operational responsibility for what runs on them; a department buying managed cloud services gets resources plus the provider's operational layer. The price difference is meaningful (30-50 percent typically) and reflects substantively different service obligations.
A procurement officer should be explicit about which category is being procured. Mixing categories within a single call-off creates contractual ambiguity that surfaces at month three.
3. Pricing dynamics under the framework
PCT 1115 awarded providers offer pricing against a published rate card. The rate card lists units (compute hours, storage gigabytes, network egress, support tiers) and unit prices. The provider commits to the rate card for the framework term, subject to defined escalation clauses.
What is not always obvious is that rate-card pricing produces wildly different total costs depending on the workload profile. A workload with predictable steady-state usage has a different cost shape from a workload with bursty usage. The framework's rate card does not force the provider to optimise the workload for the department; it provides the unit pricing the department pays for whatever consumption pattern occurs.
The procurement officer's discipline is to specify a target consumption profile in the call-off specification, ask each provider to model the total cost on that profile, and select on the modelled total cost rather than on the rate card alone. The difference between providers can be 25-40 percent of the total spend, even when their rate cards look similar.
4. The B-BBEE overlay
PCT 1115 award conditions include B-BBEE recognition and sub-contracting commitments for skills transfer. Awarded providers have committed to specific B-BBEE outcomes and to channelling a portion of the work through smaller South African ICT firms.
For the department's own preferential procurement scorecard, the call-off needs to be structured so the B-BBEE recognition flows through. This is not automatic. The framework permits the recognition; the call-off agreement realises it. A procurement officer who calls off without checking the B-BBEE flow-through later discovers the department's scorecard isn't reflecting the spend.
The fix is a paragraph in the call-off specification requiring the provider to demonstrate, in writing, the B-BBEE recognition the call-off produces, with the recognition level and the supporting documentation attached to the first invoice. A procurement officer asking for this routinely receives it.
5. Where the framework has gaps
The framework as currently structured does not fully cover three areas that matter for many departments.
Data sovereignty: cloud workloads under the framework may be hosted in South African data centres or in international data centres, depending on the provider and the service. For departments processing personal information under POPIA, this distinction matters. The framework permits both; the call-off specification needs to require South African hosting where the data residency requirement applies.
Artificial intelligence services: AI services (generative AI, machine learning platforms, foundation models) are evolving faster than the framework can update. Some AI services are within the framework's scope; others require a separate procurement route. A procurement officer evaluating an AI workload under PCT 1115 should confirm with SITA in writing whether the specific service is in scope.
Hyperscaler choice: the framework's awarded providers offer cloud services on multiple hyperscalers (AWS, Microsoft Azure, Google Cloud, sometimes others). The department's choice of hyperscaler has long-term consequences (skills, partner ecosystem, exit complexity) that the rate card does not capture. The call-off specification should drive the hyperscaler choice, not the provider.
The call-off specification checklist
A short procurement-officer's checklist for a PCT 1115 call-off: state the cloud category being procured (IaaS, PaaS, SaaS, or managed services) unambiguously; state the data residency requirement (SA hosting, regional hosting, or no constraint); state the hyperscaler choice if the workload has dependencies on a specific hyperscaler; require the provider to model total cost on a specified consumption profile, not just to quote against the rate card; require written demonstration of the B-BBEE recognition flowing to the department; specify the service-level targets and the credit structure; specify the exit plan for workloads at the end of the call-off; and specify the data extraction obligation at exit.
Each of the above is a paragraph. Together they convert a generic call-off into a specific contract that the department's auditors can evaluate and the provider's operations team can deliver against. The procurement effort is modest. The avoided cost in mis-specified call-offs is considerable.
This piece reflects experience supporting departmental cloud procurement under PCT 1115 and related frameworks. Specific call-offs should be reviewed against current SITA framework documentation, which has been updated several times since the original 2021 award.
