Vendor Section 01
Purpose and scope
This Vendor Management Program describes how Kool&Tech identifies, evaluates, approves, contracts with, monitors, renews, and offboards vendors whose products or services may support Kool&Tech operations, customer services, integrations, infrastructure, data processing, security, or business continuity.
Vendor Section 02
Program objectives
The program seeks to align vendor use with business need, evaluate risk proportionately, define accountability, establish appropriate contractual protections, monitor material changes, manage incidents and dependencies, and support an orderly transition when a relationship ends.
Vendor Section 03
Program summary, not certification
This public program summary describes intended governance practices. It is not a certification, audit report, guarantee that every vendor has identical controls, or promise that third-party risk can be eliminated.
Vendor Section 04
Governance
Vendor governance may involve business ownership, technical review, security, privacy, legal, finance, operations, continuity, procurement, and executive approval according to vendor risk and the nature of the relationship.
Vendor Section 05
Vendor owner
Each material vendor should have a designated internal owner responsible for business need, relationship oversight, access, renewal, issue escalation, evidence, and offboarding coordination.
Vendor Section 06
Vendor lifecycle
01IdentifyDocument the need, service, owner, data, access, dependencies, and alternatives.
02AssessReview risk, security, privacy, resilience, legal, financial, and operational factors.
03ApproveAccept, mitigate, condition, escalate, or reject the proposed relationship.
04ContractEstablish applicable scope, protections, responsibilities, and exit terms.
05MonitorReview performance, incidents, changes, dependencies, and continued suitability.
06Renew or exitReassess, renegotiate, replace, transition, or offboard the vendor.
Vendor Section 07
Vendor inventory
Kool&Tech may maintain a vendor inventory containing the vendor name, service, owner, category, business purpose, systems, data, access, contract references, renewal information, risk tier, dependencies, and review status appropriate to the relationship.
Vendor Section 08
Risk classification
Vendor classification may consider service criticality, data sensitivity, privileged access, integration depth, hosting responsibility, transaction authority, customer impact, replaceability, concentration, geographic exposure, regulatory relevance, and outage consequences.
Vendor Section 09
Critical vendors
A critical vendor supports a capability whose material failure, compromise, or unavailability could significantly affect essential services, security, customer data, legal obligations, or recovery. Critical designation requires evidence and context rather than vendor size alone.
Vendor Section 10
High-risk vendors
High-risk vendors may process sensitive information, hold privileged access, enable high-impact actions, host important systems, or create meaningful security, privacy, operational, legal, financial, or continuity exposure.
Vendor Section 11
Standard and lower-risk vendors
Standard or lower-risk vendors may receive a proportionate review based on limited access, low data sensitivity, low criticality, ease of replacement, or constrained use. Lower classification does not eliminate ownership or basic due diligence.
Vendor Section 12
Subprocessors
Vendors processing Personal Data on behalf of Kool&Tech or a Customer may be treated as Subprocessors when the applicable legal role and service configuration require it. The current contractual list is maintained separately in the Subprocessor List.
Vendor Section 13
Fourth-party dependencies
Review may consider material subcontractors, hosting providers, AI providers, infrastructure layers, and other downstream dependencies where information is available and risk warrants assessment.
Vendor Section 14
Vendor intake
Before material use, the requester should describe the business need, intended users, data categories, integrations, permissions, environments, payment model, alternatives, implementation timeline, and business owner.
Vendor Section 15
Due diligence
Due diligence is risk-based and may use questionnaires, documentation, certifications, reports, contracts, architecture information, provider trust centers, references, demonstrations, testing evidence, or management review.
Vendor Section 16
Security review
Security review may address identity, authentication, access control, encryption, logging, vulnerability management, secure development, incident response, infrastructure, data segregation, administrative access, and independent assurance where relevant.
Vendor Section 17
Privacy review
Privacy review may address legal role, processing purpose, Personal Data categories, data subjects, instructions, location, transfers, retention, deletion, data-subject support, Subprocessors, and contractual processing terms.
Vendor Section 18
Business continuity review
Continuity review may address availability, backup, restoration, resilience, recovery objectives, incident communications, geographic dependencies, support channels, service status, concentration, and exit alternatives.
Vendor Section 19
Compliance review
Review may consider applicable laws, contractual obligations, sector requirements, licensing, sanctions, export controls, accessibility, records, audit requirements, and relevant certifications or attestations.
Vendor Section 20
Legal and contract review
Review may consider scope, term, renewal, pricing, confidentiality, intellectual property, data use, security, incident notice, liability, indemnity, insurance, audit, subcontractors, suspension, termination, and transition.
Vendor Section 21
Financial and viability review
For material relationships, Kool&Tech may consider pricing structure, budget, payment terms, unexpected usage cost, commercial stability, financial indicators, insurance, ownership changes, and dependence on continued vendor viability.
Vendor Section 22
Reputation and integrity review
Where relevant, Kool&Tech may consider credible public information regarding security events, legal actions, sanctions, ethical concerns, misleading claims, service history, and the vendor response to known issues.
Vendor Section 23
Data and access mapping
The assessment should identify what data the vendor can receive, create, infer, transmit, store, export, or delete; what systems it can access; whether access is read, write, send, delete, or administrative; and which Customers may be affected.
Vendor Section 24
Least privilege and access
Vendor access should be limited to approved purposes, systems, roles, data, duration, and environments. Privileged access, shared accounts, persistent credentials, and production access require stronger justification and safeguards.
Vendor Section 25
Approval decisions
A vendor may be approved, conditionally approved, approved with mitigations, escalated for risk acceptance, limited to a pilot, deferred, or rejected. Approval applies only to the reviewed scope and configuration.
Vendor Section 26
Risk exceptions
An exception should identify the unmet requirement, business justification, risk, affected services or data, compensating controls, accountable approver, expiry or review trigger, and remediation or exit plan where appropriate.
Vendor Section 27
Contract controls
Contract protections are selected according to role, leverage, service, and risk. Not every vendor contract will contain identical terms, but material gaps should be understood and accepted or mitigated.
Vendor Section 28
Confidentiality
Contracts or other binding terms should address protection and permitted use of confidential information where the vendor receives or can access Kool&Tech or Customer confidential information.
Vendor Section 29
Data protection terms
Where required, applicable data-processing terms should define instructions, security, confidentiality, Subprocessors, assistance, incident notice, transfers, deletion or return, and other obligations appropriate to the processing.
Vendor Section 30
Incident notification
Material vendors should provide incident reporting through the applicable contract or provider terms where feasible. Notification needs depend on role, affected data, impact, investigation, law, and Customer obligations.
Vendor Section 31
Assurance and audit evidence
Assurance may include certifications, independent reports, questionnaires, test summaries, penetration-test information, provider documentation, or contractual audit rights. Evidence method should be proportionate and protect other customers and sensitive security information.
Vendor Section 32
Subcontractor controls
Where relevant, contracts or provider terms should address the vendor use of subcontractors, responsibility for performance, notice or disclosure, data-processing obligations, and material downstream risk.
Vendor Section 33
Performance monitoring
Monitoring may include service availability, support, delivery, contractual commitments, usage, cost, incidents, recurring defects, change notices, responsiveness, and Customer impact.
Vendor Section 34
Security monitoring
Kool&Tech may monitor credible alerts, advisories, incident notices, threat information, provider communications, known vulnerabilities, exposed credentials, and other risk signals relevant to active vendors.
Vendor Section 35
Material vendor changes
Changes involving ownership, service architecture, data location, Subprocessors, authentication, pricing, product discontinuation, scope, security posture, or terms may trigger reassessment or contractual action.
Vendor Section 36
Periodic reassessment
Reassessment frequency and depth depend on classification, contract cycle, incidents, material changes, available evidence, customer requirements, and risk. This public program does not promise one universal review interval.
Vendor Section 37
Vendor incidents
During a vendor incident, Kool&Tech may validate impact, preserve evidence, restrict access, rotate credentials, communicate with affected parties, engage the vendor, implement workarounds, track remediation, and reassess continued use.
Vendor Section 38
Vendor outages
Vendor outages may require escalation, status monitoring, workaround evaluation, recovery validation, Customer communication, and continuity action according to the affected service and contractual responsibilities.
Vendor Section 39
Concentration risk
Kool&Tech may consider dependence on a single provider, region, identity system, cloud platform, AI model, payment processor, communications provider, or other shared dependency whose failure could affect multiple services.
Vendor Section 40
Geographic and jurisdictional risk
Assessment may consider service locations, data locations, cross-border transfers, legal jurisdiction, regional resilience, sanctions, government access risk, and availability of practical alternatives.
Vendor Section 41
AI vendor risk
AI vendor review may address data use, training, retention, model behavior, safety controls, access, prompts and outputs, Subprocessors, intellectual property, availability, transparency, and support for Customer obligations.
Vendor Section 42
Software and open-source dependencies
Where relevant, vendor or product review may consider software provenance, supported versions, vulnerability response, update practices, dependencies, licensing, secure development evidence, and component transparency available from the provider.
Before material renewal, Kool&Tech may review continued business need, performance, incidents, risk changes, commercial terms, alternatives, unresolved issues, contract changes, data use, and exit readiness.
Vendor Section 44
Exit and transition planning
Material vendors should have a practical transition approach appropriate to criticality, including replacement options, timing, exports, documentation, credentials, dependent integrations, support, and continuity risks.
Vendor Section 45
Data return and export
Where applicable, offboarding should address available data exports, formats, deadlines, ownership, secure transfer, validation, and any separately scoped migration or transformation work.
Vendor Section 46
Data deletion and retention
Deletion or return follows the contract, DPA, provider capability, legal holds, backup lifecycle, and Data Retention & Deletion Policy. Kool&Tech will not claim verified deletion beyond available contractual and technical evidence.
Vendor Section 47
Access and credential revocation
Offboarding may include disabling accounts, revoking OAuth grants, rotating keys and secrets, removing certificates, ending delegated administration, disconnecting integrations, and confirming access removal where supported.
Vendor Section 48
Program records
Kool&Tech may retain intake records, assessments, approvals, contracts, evidence, exceptions, incidents, performance notes, reassessments, renewals, and offboarding records according to legal and operational needs.
Vendor Section 49
Program metrics
Program metrics may track vendor inventory coverage, overdue reviews, open findings, exceptions, incidents, renewals, offboarding status, and remediation where useful. Metrics are internal governance tools and do not create external warranties.
Vendor Section 50
Relationship to other documents
The Security & Trust Center, DPA, Subprocessor List, BCDR Summary, Data Retention & Deletion Policy, MSA, and service-specific agreements govern their respective subjects and complement this program.
Vendor Section 51
Program updates
Kool&Tech may update this program as services, vendors, threats, laws, architecture, and customer requirements evolve. Updates do not amend signed contractual commitments unless permitted by the governing agreement.
Vendor Section 52
Vendor management contact
Questions about vendor governance, due diligence, Subprocessors, material dependencies, or contractual vendor requirements may be sent to info@koolandtech.com. Security incidents should use the authorized security or support channel.