1.1. Purpose

Airports Company South Africa SOC Ltd hereby invites proposals for the supply, installation, commissioning,

testing, maintenance and support of an Intelligent Integrated Security Platform system for the period of 5

years (60 months).

1.2. Objective

The objective of this procurement is to obtain a technology solution that must add value to ACSA’s existing

security services and take into account its existing system architecture. The solution must support the following

strategic objectives:

• Improve efficiencies and incident response rates;

• Digitisation and automation of ACSA airports and facilities’ security systems;

• Cost optimisation;

• Efficient allocation of people resources;

• Drive higher levels of security;

• Improve the safety and security of people, assets and information;

• Centralise security data and information;

• Reach set security level targets;

• Optimise existing system architecture;

• Increase the threat response rate;

• Improve the quality of security data and information (accuracy, timeliness, completeness and

relevance);

• Improve overall awareness of any situation or current status of the airport;

• Improve business continuity;

• Increase the confidence level of employees, at all levels, to respond accurately to potential security

breaches;

• Improve management decision making; and

• Design and implement solutions with potential commercial value.

Confidential

1.3. Background

Airport security provides an environment wherein passengers, staff, aircraft, and airport property are given

assurance and protection from accidental or malicious harm, crime, terrorism and other unlawful acts.

Evolution of airport security environments and rapid technological advancement has in recent years

highlighted the need for airports around the world to develop and co-ordinate their security systems and

functions into well-managed and streamlined operations. Effective airport security management involves far

more than having the right security systems in place - it requires systems to be integrated and services to be

continually updated and managed from centralised locations.

As noted by the South African Civil Aviation Authority (SACAA), “the primary objective of international civil

aviation security is to ensure the protection and safeguarding of passengers, crew, ground personnel, the

general public, aircraft and facilities of an airport serving international civil aviation, against acts of unlawful

interference perpetrated on the ground or in-flight”. In response to the risk posed by these threats, Airports

Company South Africa (ACSA) has deployed various security systems and techniques, such as access

control and closed-circuit television, to ensure the safety of its airports. These systems currently operate

independently of each other and are not integrated on a single platform. In addition, the lack of integration

has resulted in suboptimal utilisation of the existing infrastructure.

Confidential

2. Scope

ACSA is looking for a solution that receives logs and events in near real time from, amongst other security

systems, Access Control, CCTV (Closed Circuit Television System), and PIDS ( Perimeter Intrusion Detection

System). This Intelligent Integrated Security Platform should perform event correlation, prioritization, and

automated even and incident response. The solution should be managed from a centralized graphical user

interface (GUI) with multiple role-based views. The solution should also be able to send out automated

notifications for priority events and incidents via email and SMS.

The following sections consist of requirements that are in scope to detect, recover and respond.

2.1. In scope

2.1.1. Functional requirements

The following are considered an integral part of business needs that are going to be enabled by

Intelligent Integrated Security Platform.

ID functional requirement

BR1 Provide an Intelligent Integrated Security System Design

Architecture

BR1.1 Delivers integrated intelligent security services

BR1.2 Considers the current environment and leverages existing security systems

BR1.3 Complies to regulatory statues such as POPIA, ICAO, CAA

BR1.4 Conforms to the open standard protocols

BR1.5 Centralise administration and storage of data

BR1.6 Geographical mapping of areas

BR1.7 Provide situational analysis or a heat map of high risk or high activity zones

BR1.8 Automation and digitalisation of standard operating procedures against predetermined policies

and business rules. In line with International Civil Aviation Organisation (ICAO), AVSEC

standards and guidelines

BR2 Graphical User Interface (GUI)

a) Operator must be able to read and write to any of the security systems from the integrated

module, e.g. acknowledge, reset and escalate alarms through the GUI.

Confidential

b) The solution GUI should be capable of utilising drawings and maps that are 3D and 2D. The

solution should support geographical mapping.

c) The GUI should be capable of being driven via a touch screen interface.

BR3 Cybersecurity

a) The cloud platform should comply and meet ISO/IEC 27001 international standard to manage

information security within the platform.

b) The Intelligent Integrated Security Platform (IISP) platform must also integrate network

monitoring tools or software to detect any abnormalities and intrusions on the security system

network.

BR4 External User Interface

The system must be able to provide different user interface view capabilities. The system should

provide configurable user interface views for airports, clusters and command centre levels

BR5 Operating Environment

a) Distributed Integrated platform: A single integration module should be able to operate all

security system data/information that is spread across the airport level, cluster level and

command centre level.

b) Completely scalable model from user to single site to Enterprise version covering multiples

airports control rooms across the airports, cluster and centralised command centre.

c) A multi-tiered hierarchy (as a federation system) centralises total control but allows individual

sites and clusters to maintain control.

BR6 Business Continuity and Redundancy

a) Integrating module must have redundancy, and in the event of primary module technical

failure, it must failover to a secondary or equivalent module to prevent any disruption of

system operation and maintain continuity of service

b) All regional airports operating from the cluster shall be equipped with a client station for

redundancy in an event network/communication to the main cluster is lost; and

c) Scalable redundancy, whereby any workstation/server can be automatically promoted to

being the primary host to connect with a single sub-system or multiple systems.

BR7 Infrastructure Specification

The Service Provider must provide the following infrastructure specifications for their system to

function optimally:

• Servers (CPU, RAM, HDD);
• Storage (any additional storage required);
• Network (e.g., ports to be opened, the bandwidth required for the solution to work optimally);

and

• Database (ACSA database standard is Microsoft SQL and Oracle).
• ACSA IT Infrastructure Standards

Confidential

• ICT Infrastructure hardware equipment that is provisioned from the appointed Service

Provider must ensure that all warranties and maintenance agreements of such hardware

equipment should be transferred to ACSA’s current maintenance contractor

• ICT Infrastructure or hardware provisioned and procured through the main contractor should

include a three year onsite replace/fix warranty of:

Critical Priority (P1)

• Complete service outage or severe business impact.
• This requires immediate attention.
• Response targets: minutes to 1 hour.

High Priority (P2)

• Significant degradation or major business impact.
• No reasonable workaround available.
• Significant degradation or major business impact.
• No reasonable workaround available.
• Response targets: 1 to 2 hours.

Medium Priority (P3)

• Moderate impact affecting some users or functions.
• Workaround may be available.
• Response targets are: 2 to 4 hours.

Low Priority (P4)

• Minor issues, requests, or non-urgent workloads/services.
• Response target: 4 hours.

BR8 Cloud/Hybrid Computing

• The proposed IISP solution should preferably be hosted in the cloud. The solution should

support hybrid computing model.

• Cloud based solutions must be hosted within South Africa or the European Union

jurisdictions.

• On premise solutions must be hosted in Tier three data centre within South Africa or the

European Union jurisdictions.

Table 3: Functional Requirements

Confidential

2.1.2. Non-functional requirements

The following are non-functional requirements that the IISP system must meet.

ID non-functional requirement

BR1 System Physical Location:

a) The system must be accessible in all 9 airports including the Corporate Office.

BR2 Solution Performance (speed and accuracy):

a) Immediate response when working on the solution. The system query response

time should be responsive near real time.

b) The system must be able to handle volumes during peak times.

c) The system must be able to cater for bandwidth constraints and geographically

dispersed locations.

d) The system must support video compression for uploads and downloads

BR3 System Response

a) All alarms, events, data, audio and video streaming exchange on the integrated module

must be in real-time

BR4 Synchronisation

a) Ability to synchronise completed incidents to the server when offline.

BR5 Scalability

a) The system must cater for future growth. e.g., adding of new functions and/or users

BR6 Usability

a) The system must be easy to use with minimal training.

b) Ease-of-use requirements must address the factors that constitute capacity of the

software; to be understood, learned, and used by its intended users. It must also conform

to usability standards for the graphical user interface.

Confidential

BR7 Reliability & Availability (Days / Hours)

a) The system must be available 24/7.

b) The solution must cater for high availability, backups and disaster recovery.

c) The system must be able to provide historical data

BR8 Security

a) The system must align with ACSA Information Security policy (Annexure D).

b) The system must support open authentication protocols including Kerberos, Open

ID Connect and Oauth.

c) The system must ensure that the data is transmitted in a non-readable format

(encrypted) and has strong key management. The system must provide encryption

capabilities for stored data to ensure that data at rest is protected.

d) Ensure that there are SSL certificates signed by the commercial CA (Certificate

Authority)

BR9 User Access Rights

a) The system must allow for users and / role-based permissions to be configured in order to

control what system features and data users can access.

BR10 Repeated authentication failure

a) The solution must notify an administrator, in line with the ASA Cybersecurity policy, if it

cannot verify the identity of any user.

b) In addition, the system should hide unauthorised functionality to users according to their

user profiles.

BR11 Integrity

a) There must be a single source of truth in terms of data and calculations where

applicable.

b) The solution must protect its communications from unauthorised intentional

corruption during transit, including communications between its users. It must also

protect its persistent data from unauthorised intentional corruption.

BR12 Privacy and data ownership

a) The system must comply with ACSA’s Information Security policies, including

POPI Act

b) All data to remain the property of ACSA and be accessible to ACSA in a format

that can be easily utilised.

Confidential

BR13 Audit Trail

a) There must be an audit trail of who created, updated, closed, and deleted (must be authorised

by the super users) the record, include the time and date stamp.

BR14 Service Access

a) All functions must be accessible via laptops, desktops, tablets, and cellphones.

b) Stakeholder management function must be accessible via laptop, desktop, mobile

and tablet.

BR10 Operational

a) Business hours are between 8 am and 7 pm. However, the system availability must be

24/7.

BR11 Business Continuity

a) The system must have an alternative way to ensure business continuity in cases

where there is an unfortunate event of downtime.

b) The system must be able to perform business functions during downtime, and the

system must be synced with the activities that were taking place during the time the system

was down.

c) The solutions recovery point and recovery time objectives should comply with the

ACSA IT Service Continuity policy which will be provided at contracting stage.

BR12 Local Support.

First line support for the solution will be done by ACSA. Second line support, by the service

provider, must be available in South Africa.

BR13 Integration:

The system should be able to integrate to the following existing applications in Section 3.1

Conceptual design of this document.

2.2. Out of scope

Any requirements that are not explicitly defined in this scope of work.

Confidential

3. Functional / systems interaction overview

3.1. Conceptual designs

Overview

The diagram below is a Conceptual architecture of an Integrated Intelligent Security Platform (IISP) which

provides a high-level view of how the airport's security systems work together as one integrated solution. It

shows the key security capabilities, how they interact, and how information flows between systems to

support monitoring, incident management, and decision-making. The conceptual design focuses on

business capabilities and operational processes rather than details in the underlying technologies,

products, or infrastructure.

Figure 2: Conceptual architecture of the Integrated Intelligent Security Platform

Confidential

Confidential

Private & Confidential

The conceptual solution design is an Intelligent Integrated Security Platform (IISP) for airports that unifies all physical

security systems, security operations, and intelligence functions into a single, layered architecture. Its goal is to

strengthen security, improve passenger experience, and increase operational efficiency, aligned with global “smart

security” concepts.

Device and Sub Layer

At the bottom, the architecture integrates all core security subsystems deployed across the airport: Access Control,

CCTV, Perimeter Intrusion Detection Systems (PIDS), Panic Alarms, E-Gates and other specialised systems. These

systems generate events, alarms, video streams and access logs.

Integrated Security Systems

Above the devices sits the Integrated Security Systems layer, centred on the Integrated Security Management (a

PSIM/ISS-type platform). The platform normalises inputs from all security subsystems and provides a single

Command and Control environment, reducing operator workload and improving situational awareness. The platform

has three core capabilities are highlighted:

• Command and Control: A single interface to monitor events, visualise locations, view CCTV and control

field devices in real time.

• Incident Workflow (SOP): Guided incident management workflows that enforce SOPs from detection

through verification, response, escalation and closure, ensuring consistent handling and full audit trails.

• Operator Action and Dispatch: Tools to dispatch patrols or responders, track status, and record all actions,

enabling faster, coordinated responses across operations and security teams.

Enterprise and External integration layer

The next layer connects IISP with three key system groups: Airport Operating Systems, Government and State

Systems, and External/Third-Party Systems. This allows the platform to exchange incident data, statuses, and risk

information with Airport Operations Database (AODB), resource management, airline, and ground-handling

systems, as well as police, immigration, and national security agencies.

Through these interfaces, the security platform participates in daily airport operations and regulatory processes, for

example: pushing security incidents that may affect operations, consuming intelligence or no-fly lists from

authorities, and sharing video or log evidence for investigations.

Intelligence and Analytics Layer

Above operational integration is the Integrated Information Security and Intelligence layer. This layer applies

Advanced Analytics, Big Data Correlation, Predictive Risk Modelling, and Cross-Domain Intelligence (IT, cyber, and

external data) to all collected information.

It transforms raw events into risk scores, early warning alerts, and trend insights, helping the airport move from

reactive to proactive security and operational management. Outputs can include predictive perimeter breach alerts,

anomaly detection of access patterns, and cross-correlation of cyber and physical incidents.

National and Strategic Command Layer

On top of the intelligence layer are the National and Cluster Command Centre and the overarching Intelligent and

Integrated Security Platform. These tiers provide regional and national views across multiple airports or clusters,

consolidating incidents, risks and performance metrics to support centralised decision‐making and coordinated

crisis management.

This design supports concepts like Aviation Security Management Systems, where security is managed holistically

across sites, based on risk and data-driven performance monitoring

Business Outcomes: Smart Security

Running vertically alongside the technical stack, the “Smart Security” column shows that the architecture is

designed to deliver three strategic outcomes:

• Strengthen Security: Unified monitoring, analytics and integration with authorities improves threat

detection, response times and compliance.

• Improve Passenger Experience: E-gates, automation and better incident management reduce queues

and disruptions, aligning with international smart security objectives.

• Increase Operational Efficiency: A single platform, standardised workflows and data-driven planning

reduce manual effort, false alarms and duplicated systems, freeing capacity and lowering operating costs.

4. System intergration list

4.1. List of existing Systems

Below is a list of existing systems that need to be integrated with the intelligent integrated Security Platform:

4.1.1.1 Access control and permit issuing – Intention is to centralise and use one

system across the organisation in future

4.1.1.2 Perimeter Intrusion Detection System – Intention is to centralise and use one

system across the organisation in future

4.1.1.3 CCTV

4.1.1.4 Passenger and Baggage Screening Systems

4.1.1.5 Queue Management System

4.1.1.6 Terrestrial Trunked Radio Communication (TETRA)

4.1.1.7 Panic and Fire Alarms

4.1.1.8 Emergency and Fire Doors

Confidential

4.1.1.9 Aircraft Gates and Emergency Gates

4.1.1.10 Patrol Badging System

4.1.1.11 Key Control System

4.1.1.12 Building Management System

4.1.1.13 Airport Management System

4.1.1.14 Smart Security Lanes

4.2. List of Future Systems

Below is a list of possible future systems that will be integrated with the intelligent integrated Security Platform:

4.2.1 Background Check System

4.2.2 Security Incidents Reporting System

4.2.3 Vehicle Intrusion Detection System

4.2.4 Biometrics (e.g. Facial & Finger)

4.2.5 Behaviour Detection System

4.2.6 Remote Piloted Aircraft System

4.2.7 Vehicle / Trucks / Containers X-ray

4.2.8 Watch list of wanted persons

4.2.9 Fleet Tracking System

4.2.10 Case Management

5. Support and maintenance

This section describes what Support and Maintenance entail in general and further describes what maintenance

entails for ACSA.

5.1. ACSA requires the Support Services from a Service Provider as described below:

5.1.1. Day to day support activities performed to remediate/report on security incidents, alerts and threat logs

generated by the system’s internal monitoring;

Confidential

5.1.2. The Service Provider will be required to respond to and remediate all incidents in line with ACSA

vulnerability management process. All security incidents will be logged on the IT service desk systems; and

5.1.3. The response and remediation times depicted below must be adhered to. This will form part of the

SLA’s that will be agreed to between the Service Provider and ACSA.

5.2. DEFINITION OF INCIDENTS, PRIORITIES AND SLA’s

Priority 1: Total system failure

Priority 2: Partial system failure with minimum monitoring functionality

Priority 3: Non-critical fault/failure logged at night or over the weekend. It has no impact on the operations

of the airport

Priority 4: Minor incidents or move/change or installation of new item

5.3. Incident management response and resolution times

Incident management response and remediation times for (Office

Hours, After Hours, Weekends and Public Holidays)

*** The service provider will be required to provide support and

maintenance on a 24/7/365 basis

Response Restoration Update Feedback

P1 15min 1hrs Every 30min

P2 30min 4hrs Every 1hr

P3 2hrs 8hrs Every 2hrs

P4 4hours 24hrs Every 8hrs

Table 4: Incident Response and Remediation Time

Confidential

5.4. Incident logging procedure

ACSA requires the Service Provider to adhere to the following incident logging procedure:

5.4.1. As per the ACSA incident management Procedure (which will be shared with the winning bidder) All security

incidents must be logged with ACSA service desk via email, telephone or on the self- service web portal.

The incident status must be updated regularly depending on the priority of the incidents until resolution;

5.4.2. All security incidents must be updated with a detailed resolution before closure. The Service Provider

must notify the service desk immediately on resolution of the incident.

5.5. IMPLEMENTATION SLAs

5.5.1. The implementation schedule (dates, milestones, success criteria etc.) will be defined in the project

kick off meeting. Should such schedule not be agreed to, it is stated that there is no consensus

between the parties, and this affects the validity of the contract.

5.5.2. The approved minutes of the kick-off meeting will serve as the agreement by the parties of the service

level and penalties.

5.5.3. The approved minutes from the kick-off meeting shall be regarded as an Appendix and form part of this

agreement

5.5.4. Where the Service Provider does not meet the implementation dates as documented and agreed by

both parties in the kick-off meeting, unless clearly and timeously communicated in writing and the

schedule re-baselined by the ACSA project manager, ACSA will notify the Service Provider of breach

of service.

5.5.5. The service provider is expected to deliver this project in line with the agreed timelines, milestones and

conditions.

5.5.6. The Supplier must propose how to best group features and provide incremental solution design,

development, testing and release plan.

5.5.7. For each release that misses the scheduled release date, and or is above System Integration Testing

(SIT) to Unit Acceptance Testing (UAT) defect leakage tolerance, ACSA will withhold 10% of the

implementation fee per such release. Defect leakage from SIT to UAT must be less than 10%

tolerance limit.

5.5.8. The solution must be in early life support for a minimum of four (4) months.

Confidential

5.6. Breach and penalties

As detailed in the next sections, the following penalties shall apply in the event of a breach of service levels as

agreed. The service provider shall restore the solution that is in scope within times specified in the service level

agreement; the following project and operational-based penalties shall apply for failing to deliver the expected

milestone or restore the services within agreed timelines:

SLA breach penalty

Project SLA Breach & Penalties

If the project milestone or release misses the scheduled 10% of the implementation fee per such release

release date and or is above SIT to UAT defect leakage will be withheld.

tolerance

Operational SLA Breach & Penalties

P1 Incidents are resolved after SLA time lapsed, for two 20% of the monthly fee will be deducted per

consecutive times in one month across any of the sites invoice and up to 60% in one contractual year.

in scope After that, termination procedures will be

implemented.

P2 to P4 Incidents are resolved after SLA time lapsed for 30% of the monthly fee will be deducted and

three consecutive times in one month across any of the up to 60% in one contractual year. After that,

sites in scope termination procedures will be implemented.

If a Service Provider misses Incident Management SLAs 50% of the monthly fee will be deducted.

in any three consecutive months across any sites in

scope

If a Service Provider misses Incident Management 50% of the monthly fee will be deducted.

SLA’s consecutive in any 4 months across all site’s ins

cope – will be deemed as a material breach, and the

contract will be referred for performance management

and/or termination procedures

Confidential

Table 5: SLA breaches and penalty for incidents

Failure to perform maintenance and/or services in accordance with the scheduled dates or Priority list and SLA

agreements shall result in the following penalties:

Maintenance Penalty

Maintenance not done or proof of carrying No payment of invoice.

maintenance out not submitted.

Table 6: Failure to provide maintenance

Confidential

6. Reporting

(a) As part of ongoing performance management, ACSA requires that the Service Provider provides the following reports as contained in the table below.

These reports will be presented to ACSA on demand and during implementation and ongoing support of the services.

(b) ACSA reserves a right to change a list of reports as requested and will review these on a regular basis, and such changes should not attract additional

costs.

(c) The project meetings will be held weekly, and/or on-demand for the duration of the contract and arranged by the ACSA Information and Enterprise

Security teams to discuss the following, but not limited to:

6.1. Weekly and monthly reports

Report Name Frequency Content and Format Submitted to

1 Service Request Status Every day of the week and a Status of new enhancements, Airport System and Enterprise Security Team

consolidated version for all 4 weeks on fixes, requests

the last day of the month (not incidents)

Confidential

2 Weekly Service Review Reports Every day of the week and a Open and closed incidents. Airport System and Enterprise Security Team

for open, closed incidents, the consolidated version for all 4 weeks on

status of each incident in terms the last day of the month Status of each incident in terms of

of SLA.

SLA.

Reason for SLA breaches, if any

and measures that will be put in

place to avoid a breach.

Report Name Frequency Content and Format Submitted to

3 Maintenance reports: report Every day of the week and a Modules worked on. Airport System and Enterprise Security Team

against the maintenance consolidated version for all 4 weeks on

schedule. This will include the last day of the month Issues discovered per module and

issues picked up during how they were resolved.

maintenance.

Details on any general

maintenance work carried out.

4 Monthly Systems Availability Last day of the month System availability Airport System and Enterprise Security

Report against the ACSA Team

required target of 99.9 % System downtime

uptime.

Confidential

5 Preventative work done. Monthly Report on various preventative Airport System and Enterprise Security

work performed Team

6 Issues for ACSA’s attention. As and when they occur Any relevant issues that need to Airport System and Enterprise Security

be brought to ACSA’s attention by Team

the Service Provider.

7 Ad-hoc As and when required Ad-hoc, depending on the request Airport System and Enterprise Security

at hand. Team

Table 6: Reporting Matrix

Confidential

7. Meetings

As part of ongoing performance management and project delivery, ACSA requires that the Service Provider attend monthly and weekly meetings.

Frequency Meeting Name Standing Agenda Participants and Role Prior documents to be Documents to be produced

after meeting submitted by the Service

Provider

Monthly Project Board Discuss all aspects of IT PMO, Service Provider’s Project Board Pack including Attendance Register

Meeting Monthly reports Service Delivery Manager, Planned Presentation.

Meeting action items ACSA contract owner, ACSA

Discuss Project Costs, Previous meeting action items Technical Lead, Project

Timeline, Risks, Issues, Sponsor, Other

Stakeholders per Invitation Monthly Reports. Resources, etc.

Discuss all deliverables

produced to trace

successful delivery on

Business Requirements.

Confidential

Weekly Progress Progress Reporting, Service Provider’s Service Minutes of Previous Meeting. Attendance Register.

Meeting Performance Management, Delivery Manager, Technical

Updated Risk and Issue Log. Meeting action items Security Posture, Security Resources and ACSA

Incidents/Threats Security team

Acceptance of deliverables.

Reporting, Exception

Reports, Risk Register,

Areas of Focus, discuss

high-level service

deliverables/milestones,

Timelines and delivery,

Environment Risks / Issues

/ Assumptions,

Contractual/Financial and

Governance, General and

all other requirements

related to the services.

Internal and External Audits

of the Services in Scope.

Ad-hoc Ad-hoc Ad-hoc Service provider & other Ad-hoc As agreed by all parties

relevant Stakeholders as

and when required

Monthly Operational Review system operations, Service provider & IT Operational reports Minutes, attendance register.

vendor performance Meetings Operations Department

Table 7: Meetings Matrix

Confidential

8. Documentation

The following project-related documentation must be produced by the Service Provider during the

implementation of the project:

• Project Management deliverables as per ACSA standards
• Architectural Design
• Functional Specification
• Technical Specification
• Interface Control Document
• Quality Assurance Specific Documentation (Test plan, Test cases, Test results for different types of solution testing

(unit, functional, performance, stress, vulnerability, List of Defects)

• Operational Manuals
• Training Manuals

9. Solution guidelines

• The solution must provide the functions and services required to support the business capability.
• There should be a single application to support a given business capability, i.e., the solution must not re- implement

a capability already available in the portfolio unless it is replacing the current one.

• The solution must be as secure as business requirements dictate.
• The solution must meet legal and conformance requirements, including those for privacy.
• The solution must provide adequate performance and responsiveness.
• The solution must be able to scale, without redevelopment, for anticipated increase in volumes for the next five

years.

• The solution must be reliable and easily recoverable.
• The solution must validate input data and maintain the integrity of any data added, updated or exported.
• The solution must provide APIs which allow services to be accessed via an interface conforming to industry

standards adopted by ACSA, e.g., Web Service (REST, SOAP).

• The solution must avoid “hard coding” of value, i.e., any variables which are likely to change must be externalised

to the database or parameter/rule files

• The solution must capture errors and report them in a meaningful and persistent way
• The solution end-user interfaces must be intuitive and standards-based to facilitate ease of adoption and reliable

usage as well as reduced training requirements.

• The solution must adhere to ACSA’s Cybersecurity policies and procedures including the patch management policy

• The solution must be documented to a standard that facilitates:

➢ Ease of installation and configuration.

➢ Ease of operation by end-users.

➢ Easy problem determination and resolution.

➢ Impact analysis for change requests.

➢ Ease of adaptation when required; and

➢ The solution must not expose ACSA to undue risk.

No eligibility criteria specified

Scope: Supply, installation, commissioning, testing, maintenance and support of an Intelligent Integrated Security Platform (IISP) for 60 months across ACSA's 9 airports and Corporate Office.

Functional requirements:

• BR1: Integrated security system design architecture delivering intelligent security services, leveraging existing systems, complying with POPIA, ICAO, CAA, conforming to open standard protocols, centralising data administration and storage, providing geographical mapping, situational analysis/heat maps, and automation/digitalisation of SOPs aligned with ICAO AVSEC standards.
• BR2: Graphical User Interface (GUI) enabling operators to read/write to security systems (acknowledge, reset, escalate alarms), supporting 3D/2D drawings and maps, geographical mapping, and touch-screen operation.
• BR3: Cybersecurity requiring cloud platform compliance with ISO/IEC 27001 and integration of network monitoring tools to detect abnormalities and intrusions.
• BR4: External User Interface providing configurable views for airports, clusters and command centre levels.
• BR5: Operating Environment supporting distributed integrated platform across airport, cluster and command centre levels; scalable from single site to enterprise; multi-tiered federation hierarchy centralising control while allowing site/cluster autonomy.
• BR6: Business Continuity and Redundancy requiring failover capability, client stations at regional airports for redundancy, and scalable redundancy with automatic promotion of workstations/servers.
• BR7: Infrastructure Specifications requiring servers (CPU, RAM, HDD), storage, network (ports, bandwidth), database (Microsoft SQL and Oracle per ACSA standards), ACSA IT Infrastructure Standards compliance, transfer of hardware warranties/maintenance agreements to ACSA's maintenance contractor, and 3-year onsite replace/fix warranty for procured hardware.
• BR8: Cloud/Hybrid Computing preferring cloud hosting (South Africa or EU jurisdictions), supporting hybrid model; on-premise option requires Tier 3 data centre in South Africa or EU.

Non-functional requirements:

• System accessible at all 9 airports and Corporate Office.
• Near real-time query response, handling peak volumes, catering for bandwidth constraints and geographically dispersed locations, supporting video compression.
• Real-time exchange of alarms, events, data, audio and video streaming.
• Offline incident synchronisation capability.
• Scalability for future growth (functions/users).
• Usability: easy to use with minimal training, conforming to GUI usability standards.
• 24/7 availability with high availability, backups, disaster recovery, historical data access.
• Security: alignment with ACSA Information Security Policy (Annexure D), support for Kerberos, OpenID Connect, OAuth, encryption in transit and at rest with strong key management, SSL certificates from commercial CA.
• Role-based user access rights.
• Repeated authentication failure notification per ACSA Cybersecurity policy, hiding unauthorised functionality per user profiles.
• Data integrity: single source of truth, protection from unauthorised corruption in transit and at rest.
• Privacy and data ownership: compliance with POPI Act, all data remains ACSA property in accessible format.
• Audit trail for create/update/close/delete actions with timestamps (delete authorised by super users).
• Service access via laptops, desktops, tablets, cellphones.
• Business hours 8am-7pm with 24/7 system availability.
• Business continuity: alternative operation during downtime, sync after recovery, RPO/RTO per ACSA IT Service Continuity Policy (provided at contracting).
• Local support: first line by ACSA, second line by service provider in South Africa.
• Integration with existing systems listed in Section 4.1 (Access Control, PIDS, CCTV, Passenger/Baggage Screening, Queue Management, TETRA, Panic/Fire Alarms, Emergency/Fire Doors, Aircraft/Emergency Gates, Patrol Badging, Key Control, Building Management, Airport Management, Smart Security Lanes) and future systems in Section 4.2 (Background Check, Security Incident Reporting, Vehicle Intrusion Detection, Biometrics, Behaviour Detection, Remote Piloted Aircraft, Vehicle/Truck/Container X-ray, Watch Lists, Fleet Tracking, Case Management).

Penalty regime:

• Project SLA breach: 10% of implementation fee withheld per release missing scheduled date or exceeding 10% defect leakage tolerance from SIT to UAT.
• Operational SLA breaches:

• P1 incidents resolved after SLA for two consecutive times in one month across any site: 20% of monthly fee deducted per invoice, up to 60% per contractual year, then termination procedures.

• P2-P4 incidents resolved after SLA for three consecutive times in one month across any site: 30% of monthly fee deducted, up to 60% per contractual year, then termination procedures.

• Missed Incident Management SLAs in any three consecutive months across any sites: 50% of monthly fee deducted.

• Missed Incident Management SLAs consecutive in any 4 months across all sites: 50% of monthly fee deducted, deemed material breach, referred for performance management/termination.

• Maintenance penalty: No payment of invoice if maintenance not done or proof not submitted.

Implementation fee and monthly fee amounts not specified in this document.

Hardware procured through main contractor must include 3-year onsite replace/fix warranty.

Hardware warranties and maintenance agreements must be transferred to ACSA's current maintenance contractor.

Regulatory compliance: POPIA, ICAO, CAA (South African Civil Aviation Authority), AVSEC standards.

Security standards: ISO/IEC 27001 for cloud platform; ACSA Information Security Policy (Annexure D); ACSA Cybersecurity Policy.

Data sovereignty: Cloud hosting in South Africa or EU jurisdictions only; on-premise in Tier 3 data centre in South Africa or EU.

Database standards: Microsoft SQL and Oracle per ACSA standards.

Infrastructure standards: ACSA IT Infrastructure Standards.

Local support: Second-line support must be available in South Africa.

No explicit CSD registration, tax clearance, B-BBEE, CIDB, CIPC, or professional registration requirements stated in this scope document.

1. Introduction 5

1.1. Purpose 5

1.2. Objective 5

1.3. Background 6

2. Scope 7

2.1. In scope 7

2.1.1. Functional requirements 7

2.1.2. Non-functional requirements 10

2.2. Out of scope 12

3. Functional / systems interaction overview 13

3.1. Conceptual designs 13

4. System intergration list 18

4.1. List of existing Systems 18

4.2. List of Future Systems 19

5. Support and maintenance 19

5.1. Support and maintenance services 19

5.2. DEFINITION OF INCIDENTS, PRIORITIES AND SLA’s 20

5.3. Incident management response and resolution times 20

5.4. Incident logging procedure 21

5.5. IMPLEMENTATION SLAs 21

5.6. Breach and penalties 22

6. Reporting 24

6.1. Weekly and monthly reports 24

7. Meetings 27

8. Documentation 29

9. Solution guidelines 29

Table 1 Glossary and Abbreviations

Table 2: Glossary Definitions

Table 3: Functional Requirements

Table 4: Incident Response and Remediation Time

Table 5: SLA breaches and penalty for incidents

Table 8: Reporting Matrix

Table 9: Meetings Matrix

testing, maintenance and support of an Intelligent Integrated Security Platform system for the period of 5

years (60 months).

1.2. Objective

The objective of this procurement is to obtain a technology solution that must add value to ACSA’s existing

security services and take into account its existing system architecture. The solution must support the following

strategic objectives:

• Improve efficiencies and incident response rates;

• Digitisation and automation of ACSA airports and facilities’ security systems;

• Cost optimisation;

• Efficient allocation of people resources;

• Drive higher levels of security;

• Improve the safety and security of people, assets and information;

• Centralise security data and information;

• Reach set security level targets;

• Optimise existing system architecture;

• Increase the threat response rate;

• Improve the quality of security data and information (accuracy, timeliness, completeness and

relevance);

• Improve overall awareness of any situation or current status of the airport;

• Improve business continuity;

• Increase the confidence level of employees, at all levels, to respond accurately to potential security

breaches;

• Improve management decision making; and

• Design and implement solutions with potential commercial value.

equipment should be transferred to ACSA’s current maintenance contractor

• ICT Infrastructure or hardware provisioned and procured through the main contractor should

include a three year onsite replace/fix warranty of:

Critical Priority (P1)

• Complete service outage or severe business impact.
• This requires immediate attention.
• Response targets: minutes to 1 hour.

High Priority (P2)

• Significant degradation or major business impact.
• No reasonable workaround available.
• Significant degradation or major business impact.
• No reasonable workaround available.
• Response targets: 1 to 2 hours.

Medium Priority (P3)

• Moderate impact affecting some users or functions.
• Workaround may be available.
• Response targets are: 2 to 4 hours.

Low Priority (P4)

• Minor issues, requests, or non-urgent workloads/services.
• Response target: 4 hours.

BR8 Cloud/Hybrid Computing

• The proposed IISP solution should preferably be hosted in the cloud. The solution should

support hybrid computing model.

• Cloud based solutions must be hosted within South Africa or the European Union

jurisdictions.

• On premise solutions must be hosted in Tier three data centre within South Africa or the

BR7 Reliability & Availability (Days / Hours)

a) The system must be available 24/7.

b) The solution must cater for high availability, backups and disaster recovery.

c) The system must be able to provide historical data

BR8 Security

a) The system must align with ACSA Information Security policy (Annexure D).

b) The system must support open authentication protocols including Kerberos, Open

reactive to proactive security and operational management. Outputs can include predictive perimeter breach alerts,

anomaly detection of access patterns, and cross-correlation of cyber and physical incidents.

5.4.1. As per the ACSA incident management Procedure (which will be shared with the winning bidder) All security

incidents must be logged with ACSA service desk via email, telephone or on the self- service web portal.

The incident status must be updated regularly depending on the priority of the incidents until resolution;

5.4.2. All security incidents must be updated with a detailed resolution before closure. The Service Provider

must notify the service desk immediately on resolution of the incident.

5.5. IMPLEMENTATION SLAs

5.5.1. The implementation schedule (dates, milestones, success criteria etc.) will be defined in the project

kick off meeting. Should such schedule not be agreed to, it is stated that there is no consensus

between the parties, and this affects the validity of the contract.

5.5.2. The approved minutes of the kick-off meeting will serve as the agreement by the parties of the service

level and penalties.

5.5.3. The approved minutes from the kick-off meeting shall be regarded as an Appendix and form part of this

agreement

5.5.4. Where the Service Provider does not meet the implementation dates as documented and agreed by

both parties in the kick-off meeting, unless clearly and timeously communicated in writing and the

schedule re-baselined by the ACSA project manager, ACSA will notify the Service Provider of breach

of service.

5.5.5. The service provider is expected to deliver this project in line with the agreed timelines, milestones and

conditions.

5.5.6. The Supplier must propose how to best group features and provide incremental solution design,

development, testing and release plan.

5.5.7. For each release that misses the scheduled release date, and or is above System Integration Testing

(SIT) to Unit Acceptance Testing (UAT) defect leakage tolerance, ACSA will withhold 10% of the

implementation fee per such release. Defect leakage from SIT to UAT must be less than 10%

tolerance limit.

5.5.8. The solution must be in early life support for a minimum of four (4) months.

5.6. Breach and penalties

P1 Incidents are resolved after SLA time lapsed, for two 20% of the monthly fee will be deducted per

consecutive times in one month across any of the sites invoice and up to 60% in one contractual year.

in scope After that, termination procedures will be

implemented.

P2 to P4 Incidents are resolved after SLA time lapsed for 30% of the monthly fee will be deducted and

three consecutive times in one month across any of the up to 60% in one contractual year. After that,

sites in scope termination procedures will be implemented.

If a Service Provider misses Incident Management SLAs 50% of the monthly fee will be deducted.

in any three consecutive months across any sites in

scope

If a Service Provider misses Incident Management 50% of the monthly fee will be deducted.

SLA’s consecutive in any 4 months across all site’s ins

cope – will be deemed as a material breach, and the

contract will be referred for performance management

and/or termination procedures

Table 5: SLA breaches and penalty for incidents

and measures that will be put in

place to avoid a breach.

• The solution must provide the functions and services required to support the business capability.
• There should be a single application to support a given business capability, i.e., the solution must not re- implement

a capability already available in the portfolio unless it is replacing the current one.

• The solution must be as secure as business requirements dictate.
• The solution must meet legal and conformance requirements, including those for privacy.
• The solution must provide adequate performance and responsiveness.
• The solution must be able to scale, without redevelopment, for anticipated increase in volumes for the next five

years.

• The solution must be reliable and easily recoverable.
• The solution must validate input data and maintain the integrity of any data added, updated or exported.
• The solution must provide APIs which allow services to be accessed via an interface conforming to industry

standards adopted by ACSA, e.g., Web Service (REST, SOAP).

• The solution must avoid “hard coding” of value, i.e., any variables which are likely to change must be externalised

to the database or parameter/rule files

• The solution must capture errors and report them in a meaningful and persistent way
• The solution end-user interfaces must be intuitive and standards-based to facilitate ease of adoption and reliable

usage as well as reduced training requirements.

• The solution must adhere to ACSA’s Cybersecurity policies and procedures including the patch management policy

• The solution must be documented to a standard that facilitates:

➢ Ease of installation and configuration.

➢ Ease of operation by end-users.

➢ Easy problem determination and resolution.

➢ Impact analysis for change requests.

➢ Ease of adaptation when required; and

➢ The solution must not expose ACSA to undue risk.

b) In addition, the system should hide unauthorised functionality to users according to their

ACSA IT Service Continuity policy which will be provided at contracting stage.

• Improve the quality of security data and information (accuracy, timeliness, completeness and

Supply, installation, support and maintenance of an Intelligent Integrated Security Platform (IISP) for a period of 60 months at Airports Company South Africa (ACSA). Bid number: COR8205/2026/RFP. Issue date: 3 September 2026.

Issue date: 3 September 2026. Non-compulsory briefing session: 18 September 2026 at 12:00 PM via Microsoft Teams (link: https://teams.microsoft.com/meet/321999536300654?p=kfRrFT4iWhw9OClmYM). Query closing date: 30 September 2026. Bid closing date and time: 16 October 2026 at 12:00 PM. Bid validity period: 120 business/working days from closing date.

Non-compulsory briefing session: 18 September 2026 at 12:00 PM via Microsoft Teams. Link: https://teams.microsoft.com/meet/321999536300654?p=kfRrFT4iWhw9OClmYM. Attendance is not mandatory but recommended for clarity on requirements.

SCM and technical enquiries: Alicia Sekoati, Category Specialist. Telephone: 011 723 1400. Email: [email protected]. Bid documents available at www.etenders.gov.za and www.airports.co.za. Submission address: Tender Box C, Airports Company South Africa SOC Limited Offices, North Wing, 3rd Floor, OR Tambo International Airport, 1 Jones Road, Kempton Park, Gauteng, 1632. Postal address: PO Box 75480, Gardenview, Gauteng, 2047. Fraud hotline: 0800 00 80 80 or 086 726 1681, email [email protected].

Submission method: hand delivery only to Tender Box C, Airports Company South Africa SOC Limited Offices, North Wing, 3rd Floor, OR Tambo International Airport. Bidders must complete and sign the Tender Deposit Register when depositing documents. Submissions must be in duplicate: one original printed copy and one printed copy of the original; the original is the legal and binding copy. Closing date and time: 16 October 2026 at 12:00 PM. Late bids will not be accepted. Queries must be submitted by 30 September 2026; responses will be shared with all bidders. Bidders may not contact any ACSA employee other than the named contact. No changes to submissions are permitted after the closing date. No consortium/joint venture member may have an interest in another bidder. Returnable forms required with the bid: SBD 3.3 (Priced offer), OEM accreditation documentation (on OEM letterhead, not older than 12 months), valid PSIRA registration certificate, signed Acceptance of Vetting form (Annexure B), reference letters, Implementation Plan, Continuity and Redundancy Plan, Integration capabilities evidence, Support and Maintenance Plan, Security and Data Protection Plan, System Architecture documentation, Company Profile, Declaration of Interest and Politically Exposed Persons form, SBD 4 (Bidder's Disclosure), SBD 6.1 (Preference Points Claim), Confidentiality and Non-Disclosure Agreement, B-BBEE certificate/scorecard or QSE/EME affidavit, medical certificate for disability preference claims (if applicable), tax PIN, Certificate of Incorporation showing ownership split, Central Supplier Database (CSD) report, VAT Questionnaire, ACSA Terms and Conditions. Disqualification risks: any mandatory returnable form left unsigned or omitted; bid received after closing time; bid document altered in any way; failure to meet mandatory requirements at Stage 1.

Mandatory returnables (Stage 1 disqualification if missing): SBD 3.3 Priced offer, OEM documentation (≤12 months), PSIRA certificate, Acceptance of Vetting form (Annexure B). Additional mandatory returnables for functionality evaluation (Stage 2): Reference letters, Implementation Plan, Continuity & Redundancy Plan, Integration capabilities evidence, Support & Maintenance Plan, Security & Data Protection Plan, System Architecture documentation. Administrative returnables: Company Profile, Declaration of Interest & PEP form, SBD 4 Bidder's Disclosure, SBD 6.1 Preference Points Claim, Confidentiality & Non-Disclosure Agreement, B-BBEE Certificate/Scorecard or QSE/EME Affidavit, Medical certificate for disability preference claims (if applicable), Tax PIN, Certificate of Incorporation with ownership split, CSD Report, VAT Questionnaire, ACSA Terms & Conditions. All documents must remain valid for contract duration; updated documents required upon expiry.

Five-stage evaluation process. Stage 1: Mandatory Requirements — bidders must submit OEM accreditation (≤12 months), valid PSIRA certificate, signed Acceptance of Vetting form (Annexure B), completed SBD 3.3. Failure to submit any leads to disqualification. Stage 2: Functionality (100 points, 70-point minimum threshold) with seven weighted criteria: Company Experience (10 pts) — ≥5 years cumulative IISP supply, installation, commissioning, support and maintenance proven by reference letters on client letterhead with contact details and signature/stamp; Implementation Plan (20 pts) — must cover executive overview, major tasks/milestones, timeline, integration approach, testing approach (unit, functional, performance, stress, vulnerability), training strategy; full 20 points if all six requirements covered and delivery within 9 months, 10 points if only four requirements covered and timeline 9–12 months; Continuity and Redundancy Plan (10 pts) — with diagrams showing failover capability; Integration Capabilities (5 pts) — evidence of open standards/protocols support; Support and Maintenance Plan (15 pts) — preventative, breakdown, corrective plans, monthly schedule, flow chart, redundancy test schedule, check sheet; Security and Data Protection Plan (10 pts); System Architecture Requirements (30 pts) — 11 specific write-ups/diagrams covering components, integration, protocols, hardware/software/infrastructure, flow diagrams, logical components, data movement, airport context, customisation, distributed platform, multi-tiered hierarchy. Stage 3: Demonstration (100 pts, 70-point threshold) — live demonstration of integration with 8 core systems (access control, perimeter intrusion detection, CCTV, passenger/baggage screening, radio communication, panic/fire alarms, emergency/fire doors, aircraft/emergency gates), central GUI with role-based access, data storage in SA and EU jurisdictions, alert mapping, situational analysis/heat map, read/write to security systems via GUI, 3D and 2D maps. Stage 4: Price and Preference (90/10 split). Stage 5: Post-tender negotiations.

Scope: supply, installation, support and maintenance of an Intelligent Integrated Security Platform (IISP) for a period of 60 months at Airports Company South Africa (ACSA) airports. Detailed scope of work in Annexure A (not provided in extracted text). Key technical requirements inferred from evaluation criteria: solution must integrate with eight core airport security systems (access control and permit issuing, perimeter intrusion detection, CCTV, passenger and baggage screening, radio communication, panic and fire alarms, emergency and fire doors, aircraft and emergency gates); provide a central graphical user interface with multiple role-based access views; store data in South African and European Union jurisdictions only; accurately interpret notifications, map breaches/intrusions, and forward alerts; provide situational analysis or heat maps of high-risk zones; allow operators to read and write to security systems from the integrated module (acknowledge, reset, escalate alarms); utilise 3D and 2D drawings and maps; support open standards/protocols; provide business continuity and redundancy with failover capability; include comprehensive support and maintenance plan (preventative, breakdown, corrective, monthly schedule, flow chart, redundancy test schedule, check sheet); include security and data protection plan; system architecture must cover 11 specified areas including component write-ups, integration approach, protocols, hardware/software/infrastructure overview, flow diagrams, logical components, data movement, airport context, customisation, distributed platform support, multi-tiered federation hierarchy. Implementation plan must be delivered within 9 months for maximum functionality points.

Implementation Plan (20 functionality points) must include: executive overview, major tasks/milestones, implementation timeline, integration approach, testing approach (unit, functional, performance, stress, vulnerability), training strategy. Maximum points for full coverage and delivery within 9 months. Continuity and Redundancy Plan (10 points) must include diagrams demonstrating failover. Integration Capabilities (5 points) require evidence of open standards/protocols support. Support and Maintenance Plan (15 points) must cover preventative, breakdown, corrective plans, monthly schedule, flow chart, redundancy test schedule, check sheet. Security and Data Protection Plan (10 points). System Architecture Requirements (30 points) require 11 specific write-ups/diagrams covering components, integration, protocols, hardware/software/infrastructure, flow diagrams, logical components, data movement, airport context, customisation, distributed platform, multi-tiered federation hierarchy.

Company Experience (10 functionality points): minimum 5 cumulative years in supply, installation, commissioning, support and maintenance of IISP solutions. Reference letters required on client letterhead with contact details and signature/stamp, each demonstrating all five requirements (supply, install, commissioning, support/maintenance, project duration). Scoring: 0 points for <5 years, 5 points for 5 years, 10 points for >5 years. Key personnel declarations required via Declaration of Interest and Politically Exposed Persons form (PEP/DPIP disclosure). Company Profile required as returnable document.

Quality assurance included as a priced line item in the pricing schedule. Testing approach must cover unit, functional, performance, stress, and vulnerability testing, documented on completion of installation. Quality assurance and testing are evaluated as part of the Implementation Plan (functionality criterion) and as separate cost items in the pricing schedule.

Pricing schedule (SBD 3.3) for 5-year contract with line items: System Design Architecture, Functional Design, Detail Design, Implementation (incl. project management), Integration, Quality Assurance, Testing (Unit, Functional, System), Hardware (network size/speed), Software (Licences), Reporting, Support & Maintenance, Training, Contingency (10%), Provisional amount for permits and parking R20,000. All-inclusive pricing in ZAR with CPI factored into grand total. VAT exclusive and inclusive totals required. Detailed itemised quotation per annum must accompany schedule. Template must not be amended; blanks filled with R0.00. Failure to use prescribed schedule leads to disqualification.

Pricing schedule (SBD 3.3) for a 5-year contract period. All amounts must be all-inclusive, in South African Rands, with CPI factored into the grand total. VAT exclusive and inclusive totals must be shown. Detailed itemised quotation broken down per annum must accompany the pricing schedule. Pricing template must not be amended; blanks must be filled with R0.00 for non-applicable items (does not exempt delivery). Line items: System Design Architecture, Functional Design, Detail Design, Implementation (including project management and resources), Integration, Quality Assurance, Testing (Unit, Functional, System), Hardware (including network size and speed), Software (Licences), Reporting, Support and Maintenance, Training, Contingency (10%), Provisional amount for permits and parking (R20,000). Bid validity: 120 business/working days with prices firm and valid for the duration. Tax compliance: bidders must submit SARS tax compliance status (TCS) PIN or CSD number; each consortium/joint venture/sub-contractor party must submit separately. Failure to provide tax compliance particulars may render the bid invalid.

Mandatory compliance documents: Central Supplier Database (CSD) registration report; valid tax compliance status (TCS PIN or CSD number); B-BBEE certificate/scorecard or QSE/EME affidavit (for preference points); PSIRA registration certificate in the bidding entity's name; OEM accreditation documentation for proposed solution (on OEM letterhead, ≤12 months old); signed Acceptance of Vetting form (Annexure B); completed SBD 3.3 (Priced offer); SBD 4 (Bidder's Disclosure); SBD 6.1 (Preference Points Claim); Declaration of Interest and Politically Exposed Persons form; Confidentiality and Non-Disclosure Agreement; Certificate of Incorporation showing ownership split; VAT Questionnaire; ACSA Terms and Conditions; Company Profile. Additional requirements: reference letters demonstrating ≥5 years IISP experience (on client letterhead with contact details and signature/stamp); Implementation Plan; Continuity and Redundancy Plan with diagrams; Integration capabilities evidence; Support and Maintenance Plan; Security and Data Protection Plan; System Architecture documentation. Medical certificate required only for disability preference claims. All submitted documents must remain valid for the contract duration; bidders must provide updated documents upon expiry. Security vetting may be required (ACSA is a National Key Point).

Preference point system: 90/10 (90 price, 10 specific goals). Specific goals points: B-BBEE Status Level 1 = 5 points, Level 2 = 4.5, Level 3 = 4, Level 4 = 3, Level 5 = 2, Level 6 = 0.5, Level 7 = 0.3, Level 8 = 0.1, Black women majority-owned entities = 5 points, Non-compliant contributor = 0 points. Documented proof required per returnable documents table. Failure to submit proof = no preference points claimed. Organ of state may require substantiation at any time.

Security and data protection plan required (10 functionality points) — must demonstrate how ACSA data will be protected and unauthorised access prevented. Business continuity and redundancy plan required (10 functionality points) — must include diagrams showing failover capability of integrating module to prevent service disruption. Support and maintenance plan (15 functionality points) must cover preventative, breakdown, and corrective maintenance, monthly schedule, flow chart, redundancy test schedule, and check sheet. These plans address operational safety and system reliability in a critical airport security environment.

Contract duration: 60 months. Bid validity: 120 business/working days with firm pricing. Confidentiality: ACSA will not disclose bidder information to third parties or other bidders without written approval; bidder names withheld until process finalised. Bidders may not disclose bid process information to third parties without ACSA written approval; third-party consultants must sign confidentiality agreements returned with the bid. ACSA is a National Key Point — security vetting may be required; ACSA will not contract with bidders failing vetting. ACSA reserves rights to: award whole or part of bid; split award; negotiate with shortlisted bidders; award to non-highest scorer where objective criteria allow; reject lowest acceptable bid; cancel bid. Bid document may not be altered; changes lead to disqualification. Fraud and corruption reporting: ACSA Tip-Offs Anonymous, free call 0800 00 80 80 or 086 726 1681, email [email protected].

Bid validity: 120 business days with firm prices. Submission: hand-delivered in duplicate (original + copy) to Tender Box C, ACSA North Wing 3rd Floor, OR Tambo International Airport by 16 October 2026 @ 12:00 PM. Original copy is legal and binding. Late bids not accepted. Queries close 30 September 2026; responses shared with all bidders. No contact with ACSA employees except listed contacts. No changes to submission after closing. No consortium/JV member may have interest in another bidder. ACSA reserves right to award whole/part, split award, negotiate, award to non-highest scorer, reject lowest, cancel bid. Document may not be altered. Confidentiality: ACSA won't disclose bidder info without approval; bidders must sign confidentiality agreements for third-party consultations. Security vetting may apply (National Key Point). Fraud hotline: 0800 00 80 80 / 086 726 1681, [email protected]. Tax compliance: TCS PIN or CSD number required; each JV/consortium party must submit separately.

Five-stage evaluation: Stage 1 — Mandatory Requirements (OEM accreditation ≤12 months, valid PSIRA certificate, signed Acceptance of Vetting form Annexure B, completed SBD 3.3). Stage 2 — Functionality (100 points, 70-point threshold): Company Experience (10 pts, ≥5 years IISP with reference letters), Implementation Plan (20 pts, 6 requirements within 9 months), Continuity & Redundancy Plan (10 pts, with diagrams), Integration Capabilities (5 pts, open standards evidence), Support & Maintenance Plan (15 pts, comprehensive), Security & Data Protection Plan (10 pts), System Architecture Requirements (30 pts, 11 write-ups/diagrams). Stage 3 — Demonstration (100 pts, 70-point threshold): integration with 8 core systems, central GUI with role-based access, data storage in SA/EU, alert mapping, situational analysis/heat map, read/write to security systems via GUI, 3D/2D maps. Stage 4 — Price & Preference (90/10 split). Stage 5 — Post-tender negotiations.