CTDISR-2025 Section 13: Third-Party and Supply Chain Risk Management

Third-party risk is one of the most difficult CTDISR-2025 sections for Pakistani ISPs to address adequately, because it requires security oversight of relationships with vendors and service providers who may have their own views on how much of their practices are your business. Section 13 requires documented vendor security assessment procedures, third-party access controls, supply chain risk management, and contractual security obligations with vendors.

The underlying principle is that your security posture is only as strong as the weakest point in your supply chain. A network equipment vendor with compromised firmware, a managed service provider with lax access controls to your systems, or a transit provider whose BGP security practices are poor can all introduce risk into your environment regardless of how well you've secured your own infrastructure directly.

Identifying Significant Third Parties

The starting point for Section 13 compliance is a register of your significant third-party relationships: vendors, service providers, and partners who have access to your systems, process your data, or supply components that are critical to your service delivery.

For a typical Pakistani ISP, the significant third parties include: upstream transit providers (PTCL, TWA, Cybernet, LINKdotNET), equipment vendors (MikroTik, Cambium, Huawei, ZTE, others depending on your stack), software and platform providers (billing platform vendors, NMS vendors, cloud service providers), co-location facility operators, and any managed service providers with access to your network.

Not every vendor relationship requires the same depth of assessment. A vendor supplying office stationery is not in scope for Section 13. A vendor supplying network equipment with management access to your core infrastructure is. Tier your vendor register by the level of access the vendor has, the criticality of the services they provide, and the sensitivity of the data they process.

Vendor Security Assessment Procedures

For each significant vendor, a security assessment documents what you know about their security practices and whether you're satisfied those practices are adequate given the access or criticality involved. The assessment doesn't require you to conduct an independent technical audit of the vendor's infrastructure, which would be impractical. It requires you to gather available information and make a documented assessment.

Available information sources for vendor assessments: the vendor's published security policies and certifications (ISO 27001, SOC 2 Type II, and similar certifications indicate a baseline security programme), their data processing agreements or security schedules in contracts, their published incident response and breach notification procedures, and for higher-risk vendors, a security questionnaire sent to the vendor directly.

The questionnaire approach works well for vendors where you have negotiating leverage and where the access justifies the overhead. For smaller vendors or commodity equipment suppliers, relying on publicly available information and contractual obligations is more proportionate.

Document the assessment with a date, the information sources used, any gaps identified, and your conclusion on whether the vendor's security posture is acceptable given the relationship. Reassess significant vendors at least annually or when the nature of the relationship changes.

Third-Party Access Controls

When vendors or service providers have access to your network or systems, that access should be subject to the same governance principles as internal access: defined scope, approved by an appropriate authority, subject to MFA where technically feasible, logged, and time-limited where practical.

The specific controls for third-party access: access should be provisioned on a need basis and documented in your access register alongside internal accounts, third-party access should have a defined scope that prevents lateral movement beyond what the relationship requires, all third-party access activity should be logged, and there should be a termination procedure that revokes access when the engagement ends or when a specific staff member at the vendor changes.

The access termination procedure is where most ISPs have gaps: access credentials provisioned for a managed service provider engagement that was completed a year ago, still active because the formal termination process was never executed. An access review that includes third-party accounts alongside internal accounts is the practical control.

Contractual Security Obligations

Contracts with significant vendors should include security obligations commensurate with the access and data involved. For vendors processing subscriber data, data processing agreements with explicit security requirements are necessary. For vendors with network access, contracts should specify acceptable use limitations, incident notification requirements (your vendor must tell you if they have a breach that affects your data or systems), and the right to audit or request evidence of compliance.

The right to audit is particularly valuable: even if you never exercise it, the contractual right means the vendor knows their practices are subject to scrutiny, which is itself an incentive for maintaining standards.

For supply chain risk specific to hardware and firmware, CTDISR-2025's supply chain risk requirements reflect global awareness that network equipment can be compromised at the manufacturing or distribution stage. For Pakistani ISPs, the practical implementation is: procure equipment through authorised distribution channels rather than grey market sources, verify firmware integrity where vendors provide verification mechanisms, and apply firmware updates through official vendor channels.

For managing vendor risk assessments, access records, and contractual security evidence in one platform, ComplianceIQ provides the structure for Section 13 evidence management alongside all other CTDISR sections. For operators building a third-party risk programme as part of a broader CTDISR compliance initiative, CTDISR Audit Readiness includes vendor risk framework development.