Vendor risk management

Purpose

Ensure every third party that processes HiringCoachAI data is vetted, contracted, documented, and reviewed using a risk-based vendor-management process appropriate to the service scope.

Risk-based approach

Vendor review is triggered when we add a production vendor, add partner SDK/API code that can send data to a third party, or materially expand the data sent to an existing vendor. The review uses a documented checklist plus automated registry-drift checks.

Lifecycle

1. Intake

Before production data is sent to a new vendor, the change record, PR, or issue captures:

• Why the vendor is needed.
• What data categories the vendor receives.
• Whether user content, authentication data, payment data, or AI prompts/completions are involved.
• Where credentials are stored.
• The assigned risk tier.
• Privacy-impact considerations, including data-subject expectations, applicable regulatory obligations, data minimization, and any harmful, unethical, or discriminatory impact risks relevant to the vendor's processing purpose.

Pre-production vendor evaluation is allowed only when no customer personal data is sent and the experiment is time-bounded. If a prototype becomes production code, it follows the contractual, technical, and documentation steps below before production data flows.

2. Contractual controls

• Contractual coverage before production data: any active sub-processor must be listed in sub-processors, the internal DPA register (available on request via [email protected]), and the data map before production customer data is sent to it.
• Data-protection terms: current sub-processors are covered by applicable data-protection terms, such as vendor DPAs, standard API terms, developer terms, or manually executed agreements where available. The internal DPA register tracks the source and verification status for each vendor.
• Liability and breach-notification posture: the internal DPA register tracks the source of each vendor's breach-notification and liability terms (available on request via [email protected]).
• Standard Contractual Clauses (SCCs): SCCs are pre-approved contractual clauses used for transfers of EU/EEA personal data to countries that do not have an adequacy decision. In practice, we rely on the SCC / transfer module in the vendor's standard DPA where the vendor offers it, and we track that posture in the internal DPA register (available on request via [email protected]).
• BAA: no Business Associate Agreement is required today because HiringCoachAI does not intentionally process PHI.

3. Technical integration

• Production and preview secrets live in Vercel environment variables.
• Local development secrets are kept in gitignored environment files and must never be committed.
• Secrets are referenced through process.env; no secret values are written into source code, compliance docs, Sentry events, or logs.
• Credentials should be least-privilege where the vendor supports scoped keys.
• Outbound HTTP requests to user-controlled URLs are routed through an SSRF-blocking helper; AI calls flow through an audited request handler that records metadata-only audit rows.
• Webhook signature verification is required where the vendor offers it, including Stripe and SendGrid events.

4. Documentation and automation

The canonical registries are:

• sub-processors: public vendor list.
• The internal DPA register (available on request via [email protected]): contractual register and DPA/SCC posture tracked per vendor.
• The data map: customer-facing data inventory that includes sub-processors and external systems.
• Internal per-vendor review notes generated or refreshed by the vendor drill.

Automation keeps these aligned:

• The public sub-processors page renders directly from the canonical markdown source, so the public surface and the compliance source share one source of truth.
• An automated vendor-code coverage audit detects active partner SDKs, API keys, hosted scripts, and API endpoints in code, and fails if the vendor is missing from the sub-processor, DPA, or data-map registries.
• An automated DPA-register coverage audit verifies every public sub-processor has a DPA-register row and a corresponding liability and breach-notification tracking row.
• An automated data-map coverage audit verifies every public sub-processor appears in the data map.
• The weekly security workflow runs these checks manually and on a schedule.

5. Ongoing review

• Weekly automated review: the scheduled GitHub security workflow runs vendor-registry, DPA-register, data-map, public-doc leakage, and compliance-claim checks. This catches most missed registry updates within a week.
• Quarterly human review: review each vendor assessment, confirm dashboard-specific DPA or terms evidence where available, confirm current security attestations, and append a dated row to the vendor's review log.
• Privacy-impact review: for vendors that collect, process, or access personal data, reassess data categories, processing purpose, regulatory posture, and any harmful, unethical, or discriminatory impact risks that could affect data subjects.
• Annually: review this policy and refresh high-risk vendor certifications / trust-center evidence.
• On material change: update the affected vendor assessment and registries when a vendor has a security incident, changes data scope, changes its published DPA, or becomes inactive.

6. Offboarding

When a vendor is removed:

• Revoke credentials and delete hosted webhooks/apps.
• Confirm deletion or export options where the vendor holds customer data.
• Move the vendor assessment to the restricted offboarded-vendor evidence set.
• Add a dated row to sub-processors.md#Historical / removed.
• Remove or mark inactive the corresponding DPA-register and data-map entries.

Risk tiers

Tier	Criteria	Controls required
Tier 1	Processes Confidential/Restricted personal data; failure threatens availability	DPA, SCC where applicable, security attestation or trust-center review, quarterly review, incident-notice posture
Tier 2	Processes Internal/Confidential data with limited blast radius	DPA or standard terms review, quarterly/annual review depending on scope
Tier 3	No personal data; low business impact	Basic ToS review and SBOM/dependency tracking

Current Tier 1 vendors: Firebase/GCP, Vercel, Cloudflare, Stripe, SendGrid, OpenAI (called both directly and via Vercel AI Gateway), ElevenLabs, Deepgram, Sentry.

Current Tier 2 vendors: Amplitude, Mixpanel, Hotjar, Meta Pixel, Google Analytics/GTM, Mailchimp, Mapbox, LinkedIn, Canva, Perplexity AI.

Current Tier 3 vendors: Node.js and open-source npm packages tracked through SBOM and patch management.

Exceptions

• Pre-production vendor evaluation with no customer personal data may proceed without a DPA, scoped to written Security Officer approval and time-bounded to 30 days.
• Production use always requires tier-appropriate controls.
• A disabled partner SDK or dormant code path is not a production sub-processor until a runtime credential/configuration enables data transfer; however, it must be noted in the internal DPA register if it is present in production code and could be enabled by environment variable.

Hardware supply chain and media disposal

HiringCoachAI does not manufacture, sell, lease, ship, or manage customer hardware, telecommunications equipment, physical appliances, embedded devices, or export-controlled computing devices. Institutions do not install HiringCoachAI hardware or agents, so a product hardware supply-chain management procedure is not applicable to the HECVAT-scoped SaaS service.

Personnel endpoint devices are governed by physical security and acceptable use. Production cloud hardware, facility, and media-disposal controls are vendor-managed by our infrastructure providers under their own audited programs.

Related

• Sub-processors: public list
• Private contractual tracking (DPA register): available on request via [email protected]
• DPA template offered to customers; contact [email protected] for execution
• Information security policy
• Data map