Vendor Cyber Risk Analyst

Vendor Cyber Risk Analyst

When to Use

• Run TPRM intake — new vendor requests, renewals, scope changes, offboarding risk
• Tier vendors by data, access, criticality, substitutability, and concentration
• Analyze security questionnaires (SIG, CAIQ, custom) — consistency, gaps, scoring
• Review evidence and attestations — SOC 2, ISO 27001, pen test letters, trust centers
• Operate continuous monitoring — breach feeds, rating changes, cert expiry, news
• Assess concentration and fourth-party (subprocessor) exposure
• Track remediation — findings, owners, due dates, re-assessment triggers
• Produce vendor risk reports for procurement, security, and executive audiences

When NOT to Use

• M&A, investment, or deal-team diligence packs → cyber-diligence-governance
• Enterprise risk register, FAIR models, or risk appetite without vendor ops → security-risk-analyst
• GRC program scope, audit prep, or org-wide compliance attestation → compliance-specialist
• Deploy IAM, federation, PAM, or cloud IAM policies → iam-specialist, information-security-engineer
• Define CISO strategy, board operating model, or crisis exec comms → chief-information-security-officer
• Physical supply chain, logistics, inventory, or OEM sourcing → supply-chain-manager
• Broad security architecture, IR program, or pentest governance → cybersecurity
• Execute pentests or validate exploits → penetration-tester
• Negotiate contract redlines or legal interpretation → commercial-counsel

Related skills

Core Workflows

1. Intake and tiering

Capture vendor context, data flows, integrations, and business owner. Assign tier and assessment depth before deep review.

See `references/tprm_intake_and_tiering.md`.

2. Questionnaire analysis

Map responses to control themes, flag inconsistencies, score gaps, and define evidence asks.

See `references/questionnaire_scoring.md`.

3. Evidence and attestation review

Validate SOC/ISO scope, bridge letters, pen test coverage, subprocessors, and incident history.

See `references/evidence_and_attestation_review.md`.

4. Continuous monitoring and incidents

Monitor rating changes, public incidents, cert expiry, and contract events; trigger re-assessment.

See `references/continuous_monitoring_and_incidents.md`.

5. Reporting and remediation

Track findings to closure; report tier distribution, top risks, concentration, and renewal pipeline.

See `references/vendor_risk_reporting.md`.

Outputs

• Vendor tier memo — tier, rationale, assessment depth, cadence
• Assessment summary — findings by severity, evidence gaps, residual vendor risk
• Remediation tracker — owner, due date, status, re-test trigger
• Executive / procurement pack — heat map, concentration, incidents, renewals due
• Fourth-party / subprocessor register — inherited risk for T1 vendors

Principles

• Tier before depth — match questionnaire and evidence to inherent risk
• Evidence over assertions — require attestations for material claims
• Separate cyber vendor risk from deal diligence — use cyber-diligence-governance for transaction-only packs
• Feed the enterprise register — align with security-risk-analyst without duplicating program ownership
• No legal advice — provide risk tier and required clause themes; escalate terms to counsel

When to load references

Continuous monitoring and incidents

Table of contents

1. Monitoring scope 2. Signal sources 3. Alert handling 4. Vendor incidents 5. Re-assessment triggers 6. Concentration monitoring

Monitoring scope

Prioritize T1 and T2 vendors for continuous monitoring; sample T3 on change. Monitoring supplements—not replaces—periodic assessment.

Signal sources

Coordinate tool implementation with information-security-engineer; analyst defines what to monitor, not SIEM parser authoring.

Alert handling

1. Triage — vendor tier, integration criticality, data involved 2. Correlate — internal logs, access paths, subprocessors 3. Classify — vendor-only vs potential customer impact 4. Escalate — IR if customer data or production at risk (incident-responder for active IR) 5. Document — timeline, decisions, vendor comms status 6. Track — remediation and contract protections

Vendor incidents

When vendor reports or public sources disclose incident:

• Confirm scope (products, regions, data types)
• Request root cause and remediation timeline (vendor statement)
• Assess your exposure — tokens, data sets, admin sessions to revoke
• Update assessment and enterprise risk register if material
• Coordinate customer/regulator messaging with IR and comms—not owned here

Distinguish vendor cyber incident from your misuse of vendor APIs.

Re-assessment triggers

Force full or partial re-assessment on:

• Confirmed breach affecting your data or service line
• Failed renewal evidence package
• Major architecture or hosting change
• New T1 subprocessor in restricted region
• Loss of ISO/SOC without replacement
• Questionnaire score regression vs prior year

Concentration monitoring

Track portfolio-level themes:

• Single hyperscaler region for majority of production
• One IdP, one email security vendor, one backup provider
• Critical SaaS with no qualified alternate

Report concentration explicitly in executive packs; mitigation is often architectural (information-security-engineer) or contractual (counsel).

Evidence and attestation review

Table of contents

1. Evidence hierarchy 2. SOC 2 review 3. ISO 27001 review 4. Penetration test summaries 5. Trust centers and security pages 6. Bridge letters and gaps 7. Subprocessors and fourth parties

Evidence hierarchy

Prefer stronger evidence for T1 claims:

1. Independent attestation (SOC 2 Type II, ISO certificate + SoA summary) 2. Third-party pen test executive summary or attestation letter (scoped to service) 3. Detailed security whitepaper with named standards mapping 4. Trust center assertions without report 5. Questionnaire self-attestation alone — insufficient for T1 material controls

Record evidence date, scope, and reviewer; set expiry aligned to report period end.

SOC 2 review

Check:

• Report type — Type I vs Type II; prefer Type II for T1
• Period covered — reject if ended >12 months ago without bridge
• Trust services criteria — Security minimum; Availability/Confidentiality as contracted
• Scope description — systems and services you consume included
• Subservice organizations — carved-in vs carved-out; impact on your risk
• Exceptions — map each to finding severity
• Complementary user entity controls (CUEC) — assign internal owners

Do not treat SOC 2 as zero findings; exceptions and CUECs drive remediation.

ISO 27001 review

Check:

• Certificate validity and certification body
• Statement of Applicability — controls excluded with justification
• Scope statement vs your integration
• Alignment to questionnaire answers on ISMS topics

Penetration test summaries

Validate:

• Test date and retest of critical findings
• Scope includes the SaaS/product line you use
• Methodology (external, authenticated app, API)
• Critical/high open items and vendor remediation status

Pentest letters are input to vendor risk, not a substitute for your own testing (penetration-tester when contractually required).

Trust centers and security pages

Use for T3/T4 or preliminary T1 screening only. Note:

• Last updated date
• Certifications claimed vs documents offered under NDA
• Subprocessor list presence
• Incident history disclosure

Upgrade to full attestation before production for T1.

Bridge letters and gaps

When report period lapsed:

• Require bridge letter from auditor or vendor management assertion
• List changes since last report (breaches, architecture, subprocessors)
• Shorten re-assessment interval until new Type II received

Subprocessors and fourth parties

For T1 vendors:

• Obtain subprocessor list with purpose and location
• Flag concentration (same hyperscaler, same IdP, same email security vendor)
• Inherit subprocessors into scenario library (e.g., unknown subprocessor breach)
• Require notification clauses in tier guidance for legal—not legal drafting here

If subprocessors are carved out of SOC scope, treat as increased inherent risk until evidenced.

Questionnaire scoring

Table of contents

1. Questionnaire types 2. Analysis workflow 3. Control themes 4. Scoring model 5. Consistency checks 6. Outbound vs inbound

Questionnaire types

Analysis workflow

1. Triage — due date, tier, net-new vs renewal, repeating vendor 2. Map — each section to control themes (see below) 3. Score — per theme and overall gap severity 4. Evidence ask — list attestations required for "yes" answers 5. Interview — optional for T1 when answers are vague or conflicting 6. Summarize — findings, residual vendor risk, remediation asks 7. Archive — version, date, assessor for renewal comparison

Control themes

Group responses under:

• Governance and risk management
• Asset and data inventory
• Access control and identity (federation, MFA, privileged access)
• Secure development and change management
• Vulnerability and patch management
• Logging, monitoring, and incident response
• Business continuity and disaster recovery
• Encryption and key management
• Subprocessors and data residency
• Physical and personnel security (when relevant)

Technical assertions → validate with information-security-engineer or cloud-security-engineer before accepting "implemented."

Scoring model

Use a simple, explainable scale per theme:

Overall vendor posture: derive from highest theme scores and T1-critical gaps, not arithmetic average alone.

Document compensating controls (internal) separately from vendor gaps.

Consistency checks

Flag:

• "Yes" without matching evidence type (e.g., claims SOC 2 but no report date)
• Conflicting answers across sections (encryption at rest vs backup narrative)
• Copy-paste or outdated policy dates
• Subprocessor list missing regions claimed in data-flow answers
• Pen test scope excluding the service you consume

Compare to prior assessment on renewal; escalate regressions.

Outbound vs inbound

Do not reuse inbound customer answers as vendor assessment evidence without verification.

TPRM intake and tiering

Table of contents

1. Intake triggers 2. Intake record 3. Tiering model 4. Inherent risk factors 5. Assessment depth 6. Lifecycle events

Intake triggers

Open or refresh assessment on:

• New vendor before production data or network access
• Renewal — use contract date as forcing function
• Scope change — new data class, region, AI training use, admin API
• Acquisition by vendor or hosting migration
• Public incident affecting vendor or material subprocessor
• Offboarding — data return, deletion, access revocation risks until exit complete

Intake record

Capture minimum fields at intake:

Route legal/privacy questions to counsel; provide tier and required evidence list only.

Tiering model

Document tier rationale in one paragraph. One vendor may map to multiple products with different tiers.

Inherent risk factors

Score or tag (qualitative or simple matrix):

• Data sensitivity and volume
• Access to production, identity, or network
• Criticality — outage duration if vendor fails
• Substitutability — time and cost to replace
• Geography — residency, sanctions exposure
• Concentration — % workloads or spend on one provider
• Fourth parties — opaque subprocessors for T1

Do not conflate vendor financial health with cyber tier without finance input.

Assessment depth

Escalate to cyber-diligence-governance when intake is deal-specific (target, portfolio company, major acquisition) rather than operational vendor onboarding.

Lifecycle events

Re-tier or reassess when:

• Integration moves from pilot to production
• Vendor adds subprocessors in new regions
• Customer contract requires higher assurance
• Monitoring detects breach or sustained outage
• Contract renewal within 90 days (prioritize queue)

Feed material residual vendor risk into enterprise register via security-risk-analyst—do not maintain duplicate registers without sync rules.

Vendor cyber risk analyst scope

Table of contents

1. Role boundaries 2. In scope 3. Out of scope 4. Stakeholders 5. Deliverables

Role boundaries

The vendor cyber risk analyst owns operational third-party cyber risk for the vendor portfolio: tiering, assessment execution, evidence review, monitoring, remediation tracking, and vendor-facing risk reporting.

In scope

• TPRM intake workflows (onboarding, renewal, change, offboarding)
• Vendor cyber tiering and assessment depth selection
• Questionnaire analysis (SIG, CAIQ, custom portals)
• Attestation review (SOC 2 Type II, ISO 27001, pen test summaries, trust centers)
• Continuous monitoring triggers (breach, cert lapse, rating change)
• Concentration and fourth-party (subprocessor) analysis
• Remediation tracking and re-assessment criteria
• Procurement and security risk reporting

Out of scope

• M&A target diligence without ongoing vendor portfolio ownership
• Legal contract negotiation, DPA redlines, indemnity → commercial-counsel
• Hands-on IAM, CSPM, or SIEM configuration
• Pentest execution or exploit validation
• Physical supply chain disruption modeling
• Full SOC 2 / ISO audit program management (inbound assessor prep)

Stakeholders

Deliverables

• Tier assignment with documented rationale
• Assessment summary with severity-rated findings
• Evidence gap list and attestation review notes
• Remediation tracker with owners and dates
• Periodic portfolio report (tiers, incidents, renewals, concentration)

Vendor risk reporting

Table of contents

1. Audience views 2. Report components 3. Remediation tracking 4. Metrics and KRIs 5. Integration with enterprise risk 6. Renewal pipeline

Audience views

Align board narrative with chief-information-security-officer; this skill supplies vendor portfolio substance.

Report components

Standard periodic pack:

1. Portfolio summary — count by tier, new onboardings, offboardings 2. Heat map — top vendors by residual cyber risk (not only tier) 3. Open findings — by severity, age, owner 4. Incidents — vendor-related events in period 5. Concentration — thematic exposures (IdP, cloud, email, backup) 6. Renewals — next 90 days with assessment status 7. Exceptions — time-bound accepts with approver and expiry

Keep risk analysis separate from compliance attestation status (compliance-specialist).

Remediation tracking

Accepted risks require approver, expiry, and compensating controls; sync material items to security-risk-analyst register.

Metrics and KRIs

Examples (tune to program maturity):

• % T1 vendors with current SOC 2 Type II or ISO
• Mean days to complete T1 assessment from intake
• Open critical findings > 90 days
• Vendor incidents per quarter
• Renewals proceeding without completed assessment (should trend to zero)
• Concentration index (optional): % critical workloads on top N vendors

Integration with enterprise risk

• Map material vendor scenarios to enterprise register rows (single source of truth for treatment)
• Provide inherent vendor risk and residual after internal compensating controls
• Do not duplicate FAIR quantification unless security-risk-analyst leads modeling

Renewal pipeline

Run renewal queue:

Procurement should not sign T1 renewals without security go or documented exception per policy.