Two regulations that matter more here than elsewhere

Regulation 39(d) requires designated CII owners to adopt procedures for regular security audits and penetration testing, and it names virtual and remote access explicitly as an area requiring control. For an airport or port operator, virtual access is not a single, well-defined boundary the way it might be for a standalone data centre. Ground handlers, airlines, customs systems, air navigation service providers, fuelling contractors and baggage-system vendors all connect into operational networks that sit adjacent to, or sometimes directly alongside, passenger and administrative IT. Regulation 39(d) is, in effect, asking whether you actually know where every one of those connections terminates.

Regulation 31(2) sets the baseline security requirements: asset identification and classification, personnel vetting, a cybersecurity awareness programme, and participation in cross-sector exercises. For transport CII, asset identification is the item operators most often get wrong, not because it's neglected, but because ground systems, navigation systems, and building-management systems are frequently managed by different teams, different vendors, and different maintenance contracts, with no single asset register that spans all of them.

What's structurally different about airport and transport OT

Energy and water CII security discussions tend to focus on SCADA and process control in a relatively contained operational boundary: one operator, one or a small number of control rooms. Transport, and aviation in particular, is different in a way that matters for how you scope an assessment:

None of this is unique to Kenya. It's a structural feature of aviation and transport environments everywhere. What Legal Notice 44 does is make addressing it a legal obligation rather than a discretionary good practice.

Form CMCA 6, the prescribed NC4 audit template, examines network security first (§3.1): firewall configuration, intrusion detection, network access control, and VLAN segmentation. For a transport operator, that section can't be answered meaningfully without first mapping which of the systems described above sit on which network segment, which is exactly the zone-and-conduit exercise IEC 62443 was built for.

Why IEC 62443 is the right anchor here, specifically

Regulation 71(3) allows CII owners to adopt global best-practice standards on their own initiative. For transport CII, the case for IEC 62443 is stronger than for most sectors, precisely because of the multi-vendor, multi-stakeholder environment described above. The standard's zone-and-conduit model exists to answer exactly this question: which systems belong in which trust boundary, and what's allowed to cross between them. Its supply-chain provisions (62443-2-4 for service providers, 62443-4-1 for product suppliers) give an operator a defensible basis for holding baggage-system, access-control, and ground-services vendors to a consistent security standard, rather than negotiating it contract by contract.

Where to start

Not with a penetration test, and not with a policy rewrite. The first defensible step for a transport CII owner is the same one Regulation 31(2)(a) already requires: a complete, classified asset inventory spanning every operational system on the site, regardless of which vendor or department manages it, followed by a zone-and-conduit model showing how those systems actually connect. Everything else, including the Regulation 39(d) testing programme, the Form CMCA 6 audit readiness, and the IEC 62443 gap assessment, depends on having that map first. Most operators we've reviewed don't yet have one that spans the whole site.