Vendor risk management

Purpose

Ensure every third party that processes or receives HiringCoachAI data, including a user-authorized connected provider, is vetted, contractually classified, 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.
• Provider-role determination: the Privacy Officer documents whether a third party is a sub-processor, user-authorized connected provider, or another relationship, with the governing terms and acceptance evidence. The Privacy Officer may approve a low- or medium-risk determination when explicit public terms clearly establish the relationship. Licensed counsel review is required for ambiguity, bespoke terms, regulated or high-risk processing, conflicting customer obligations, or Privacy Officer escalation.
• 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 and connected providers: Amplitude, Mixpanel, PostHog, Meta Conversions API, Mailchimp, Mapbox, LinkedIn, Canva, Perplexity AI, and Microsoft Graph / Outlook Calendar.

OpenWeb Ninja JSearch is a planned Tier 2 vendor. The implementation and credentials are present, but production requests fail closed until its DPA and SCC/transfer posture is recorded and the separate Production enable flag is explicitly set.

Hotjar, Google Analytics/GTM and container-loaded LinkedIn Insight tags, and the client Meta Pixel were disabled on 2026-07-29. Their vendor and DPA records remain in the audit register, but they are not current browser processors.

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 user-authorized connected provider does not require a processor DPA when the documented governing terms establish that no HiringCoachAI-to-provider processor relationship exists. The Privacy Officer determination, terms source, technical controls, and any residual risk must still be recorded before production use.
• 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