Risk-based vendor assessment framework for IT service providers, technology vendors, and third-party partners under DORA, NIS2, GDPR. Provides three-phase process (Initial Screening / Detailed Assessment / Final Evaluation), six-dimension risk scoring (Financial/Operational/Compliance/Security/Reputational/Strategic) with weighted matrices, full DORA Art. 28-30 contractual checklist, NIS2 Art. 21(2) security measures enumeration, GDPR Art. 28 documentation checks, red flags per dimension, trigger-based review criteria, and document templates. Use when: (1) Evaluating new vendors or technology providers, (2) Conducting critical ICT third-party due diligence under DORA, (3) Performing supply chain security assessment under NIS2, (4) Creating vendor onboarding documentation, (5) Establishing ongoing vendor monitoring, (6) Assessing concentration risk, or (7) Generating executive vendor risk reports.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Risk-based vendor assessment framework that identifies material risks early, ensures DORA/NIS2/GDPR compliance, and provides clear recommendations for selection, contract calibration, and ongoing management. Built for regulated sectors (financial services under DORA, KRITIS sectors under NIS2) and for any organisation with meaningful ICT third-party exposure.
This skill provides frameworks for vendor assessment purposes only. It does not constitute legal, financial, or professional advice. Users should:
The frameworks are templates. Actual assessments require expertise in law, finance, cybersecurity, and risk management. Neither the skill creator nor Claude/Anthropic assumes liability for decisions made based on this skill's output.
Regulatory references current as of 2026-04-23. EU (DORA, NIS2, GDPR) and German (NIS2UmsuCG, BDSG) citations reflect the consolidated text available at that date. Member State NIS2 transposition remains uneven; Germany's NIS2UmsuCG entered into force on 6 December 2025 with the BSI reporting portal opening on 6 January 2026. Verify the current consolidated text and national transposition status on EUR-Lex and the Bundesgesetzblatt before use.
Phase 1: Initial Screening (1-2 days): rapid assessment to determine whether a vendor warrants detailed evaluation.
Phase 2: Detailed Assessment (1-2 weeks): comprehensive evaluation across all risk dimensions. See Section 2.
Phase 3: Final Evaluation (3-5 days): synthesis, risk scoring, mitigation strategies, recommendation.
Documents to request: 3 years audited financial statements; commercial credit report; professional liability insurance (€5M minimum); cyber insurance (€5M minimum for IT vendors); banking references.
Analysis: revenue trends and profitability; debt levels and liquidity ratios; customer concentration risk; financial stability score (1-5).
Red flags: consistent losses or negative cash flow; high customer concentration (>30% revenue from one client); recent credit downgrades; inadequate insurance coverage.
Documents to request: articles of incorporation and bylaws; material contracts (top 5 customers and suppliers); pending and historical litigation; regulatory filings; IP portfolio; data protection policies and GDPR documentation; subprocessor list (if data processor).
GDPR compliance review (Art. 28 GDPR): privacy policy and notices; DPA template; breach incident response procedures; international data transfer mechanisms (SCCs, adequacy); Art. 30 records of processing; DPIA process for high-risk processing.
Industry-specific: financial services clients - DORA compliance (Art. 28-30); KRITIS sectors - NIS2 compliance (Art. 21); AI systems - AI Act classification and compliance.
Red flags: pending significant litigation (>10% annual revenue); regulatory enforcement actions; material IP infringement claims; GDPR non-compliance (no DPA, inadequate security).
Documents to request: security certifications (ISO 27001, SOC 2 Type II, PCI DSS where applicable); recent penetration testing results; security incident history (3 years); business continuity and disaster recovery plans; backup procedures and testing records; technical architecture diagrams; data residency documentation; subprocessor security assessments.
Security assessment: encryption standards (at rest and in transit); access controls and identity management; vulnerability management program; security awareness training; incident response procedures and SLAs; third-party security audits.
NIS2 Art. 21(2) security measures (for KRITIS vendors), mapped to the ten statutory sub-paragraphs:
DORA ICT risk management (for financial services vendors): Art. 6-16 ICT risk management framework; Art. 17-23 incident management; Art. 24-27 digital operational resilience testing; Art. 28-30 third-party risk monitoring.
Red flags: no ISO 27001 or equivalent; no SOC 2 Type II; recent major security incidents with inadequate response; inadequate backup and DR; data residency non-compliance.
Documents to request: SLA performance history (12 months minimum); customer satisfaction metrics; support structure and escalation procedures; change management and release procedures; service availability statistics; MTTR data.
Analysis: service delivery track record; support responsiveness; technical competency; scalability; exit/transition procedures.
Red flags: consistent SLA failures; poor customer references; inadequate support infrastructure; no documented exit procedures.
Score each vendor 1 (Low) to 5 (Critical) across dimensions. Weighted matrix:
| Category | Weight | Score | Weighted Score |
|---|---|---|---|
| Financial Risk | 20% | ||
| Operational Risk | 25% | ||
| Compliance Risk | 30% | ||
| Security Risk | 15% | ||
| Reputational Risk | 5% | ||
| Strategic Risk | 5% | ||
| TOTAL | 100% |
Critical services (payment processing, customer data systems, core business operations) receive 2x weight on security and compliance factors.
Risk score interpretation:
For financial services clients, DORA Art. 28-30 impose enhanced requirements for ICT third-party service providers.
DORA Art. 28 - General Principles: comprehensive ICT third-party risk management framework; full contractual documentation of all services; identification of all ICT third-party dependencies; comprehensive exit strategies.
DORA Art. 30 - Mandatory Contract Elements: service description (clear, complete, up-to-date); service locations (including subcontracting); service levels (SLAs with measurement and reporting); GDPR-compliant DPA; minimum security standards; availability and business continuity (DR/BCP); detailed exit strategy; regular and for-cause audit rights; subcontracting prior notification with objection rights; access for authorities (BaFin, ECB, ESMA inspection rights); termination rights (material breach, regulatory concerns); appropriate liability allocation; notice requirements for material changes, incidents, regulatory changes.
Concentration risk (Art. 28(4)): is the vendor used by multiple financial entities? Does this create systemic risk? Are alternatives available? What is our dependency level?
Substitutability (Art. 28(4) read with Art. 29): can we switch vendors within 3-6 months (illustrative planning horizon; DORA itself requires "adequate transition periods" under Art. 30 rather than a fixed window)? Technical lock-ins? Data portability? Contractual barriers to exit?
ICT sub-outsourcing (Art. 30(2)(a), read with the Commission Delegated Regulation on subcontracting RTS, JC 2024 53): all subcontractors identified; subcontractor locations documented; subcontractor security verified; subcontractor change notification process.
For vendors in NIS2 scope (KRITIS sectors under essential/important entity obligations), Art. 21 requires cybersecurity risk management measures.
Required assessments against Art. 21(2) measures are enumerated in Section 2 above. Supply chain security (Art. 21(2)(d)): vendor's own cybersecurity measures verified; vendor's supply chain security practices assessed; contractual cybersecurity obligations included; regular vendor security reviews; vendor incident notification requirements.
Financial: shorter contract terms (1-2 years); payment terms protecting buyer (Net 30 vs. advance); parent company guarantees; performance bonds or escrow; more frequent financial reviews.
Compliance: enhanced contractual GDPR, DORA, NIS2 provisions; quarterly audit rights; regular compliance attestations; mandatory notification of regulatory changes; stricter SLAs with termination rights for non-compliance.
Security: required certifications as ongoing obligation; annual penetration testing at vendor cost; incident notification within 24 hours vs. 72; enhanced monitoring and logging; MFA requirements; regular security assessments.
Operational: robust SLAs with meaningful service credits; detailed exit and transition procedures; source code escrow for critical applications; dual sourcing for critical services; more frequent performance reviews.
Strategic: limit contract term; build exit provisions; avoid proprietary lock-in; maintain dual-source options.
Quarterly reviews: SLA compliance; service quality; security incidents; financial stability (where quarterly data available); compliance status.
Annual assessments: update full risk scoring matrix; contract performance and commercial terms review; market alternatives and pricing; strategic alignment; renewal or termination decision.
Trigger-based reviews (immediate): major security incident or data breach; regulatory enforcement action; material litigation; financial distress (credit downgrade, significant losses); acquisition or ownership change; service quality deterioration; repeated SLA failures; material contract breach.
Vendor Risk Report (10-20 pages): executive summary; vendor background; financial assessment; legal and compliance review; security and technical evaluation; operational assessment; risk scoring matrix with justifications; mitigation recommendations; recommended contract terms; implementation and monitoring plan; appendices.
Vendor Assessment Summary (2-3 pages): vendor overview and services; risk score summary table; key findings; recommendation (proceed/conditional/reject); required contract terms; next steps.
Vendor Comparison Matrix: side-by-side risk scores; compliance coverage comparison; cost-benefit analysis; strengths/weaknesses; recommended vendor with justification.
Vendor Risk Register (spreadsheet): vendor name and ID; service type and criticality; risk scores by category; overall rating; last assessment date; next review date; key risks and mitigations; contract key terms; primary contact; escalation contacts.
Vendor Onboarding Checklist: due diligence completed and approved; contract negotiated and executed; insurance certificates received; DPA signed; security documentation reviewed; access provisioning completed; integration plan approved; service transition timeline; monitoring procedures implemented; relationship management assigned; vendor added to risk register; first quarterly review scheduled.
This skill does not: replace professional due diligence services; provide legal advice; guarantee vendor performance or eliminate risk; substitute for organisation-specific risk frameworks; fulfill regulatory obligations without expert validation; create attorney-client or fiduciary relationships.
Users must: adapt frameworks to their specific industry, jurisdiction, and risk tolerance; engage qualified professionals for regulated assessments; verify current regulatory requirements; obtain internal approvals; maintain documentation for audit and compliance; update criteria as regulations evolve.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Creates an Agent Authority Charter for enterprise or regulated AI agents before deployment. Use this Skill when a user needs to define what an AI agent is allowed to do, who delegated authority to it, what actions are permitted or prohibited, when human approval is required, what evidence must be preserved, and how the agent can be suspended, revoked, or escalated.
日本語の概要は準備中です。原文の説明を表示しています。
EU AI Act Knowledge Engine — authoritative regulatory Q&A grounded in 70 official EU source documents (including the 2026 Commission draft guidelines on Art. 6 high-risk classification — general principles, Annex I, Annex III). Answers any question about the AI Act with article-level citations from the full regulation text, Commission guidelines, EDPB/EDPS opinions, codes of practice, harmonised standards, FRIA guides, incident templates, and sector-specific guidance. This skill should be used when the user asks about the "EU AI Act", "AI Act regulation", "Regulation 2024/1689", "KI-Verordnung", asks to "explain an AI Act article", "what does Article X say", "AI Act requirements", "AI Act penalties", "AI Act timeline", "GPAI obligations", "high-risk AI", "prohibited AI practices", "AI Act and GDPR", "fundamental rights impact assessment", "AI Act standards", "AI Act national implementation", "AI literacy", "serious incident reporting", "Digital Omnibus", "AI regulatory sandbox", or any question about EU artificial intelligence regulation. Also triggers on German terms: "KI-Gesetz", "KI-Verordnung", "Hochrisiko-KI", "KI-Kompetenz", "Grundrechte-Folgenabschaetzung", "GPAI-Verhaltenskodex". For assessment workflows that produce a classification decision rather than a knowledge answer, offer to run a structured risk-tier classification in-session.
日本語の概要は準備中です。原文の説明を表示しています。
This skill builds a structured audit trail of an AI-assisted task: what the tool was asked to do, what materials it was given, what it produced, how the output was verified, and what was ultimately relied upon. It documents the workflow for supervision and later review without ruling on privilege or disclosure, so the record stays accurate rather than self-serving.
日本語の概要は準備中です。原文の説明を表示しています。
Use this skill when the user wants an AI governance, legal-risk, privacy, compliance, procurement, or vendor-risk review of an internal AI use case, an AI product feature, an LLM workflow, or a third-party AI vendor. The skill asks intake and clarifying questions first when facts or evidence are missing, identifies required documentation and missing evidence, maps the use case to AI governance frameworks and applicable legal domains, and produces a preliminary or final governance review with scorecards, findings, owners, remediation actions, and follow-up questions.
日本語の概要は準備中です。原文の説明を表示しています。
Turn an interpretive-ambiguity audit of a legal text — contract, statute, regulation, or judicial opinion — into a polished deliverable. Produces a multi-page website (default), a single-page interactive site, a Microsoft Word document, a PowerPoint deck, or a LaTeX/PDF. Use whenever a user has a stress-test result, ambiguity audit, or "where will this be litigated" scenarios and wants to publish, present, or share them. Triggers on "publish the audit," "make a report from this," "turn this into a website / deck / brief / Word doc," "make a Netlify site," "build slides of these ambiguities," "render the scenarios," "package this stress test," "produce a LaTeX version," and similar. Pairs with the ambiguity-stress-test skill (the underlying analysis) but works on any structured or semi-structured ambiguity analysis. Visual design is opinionated but the user can override colors, fonts, and brand label. Most formats need Python and a writable filesystem; single-file HTML works where the host has neither.
日本語の概要は準備中です。原文の説明を表示しています。
Adversarially stress-tests a legal text — a contract, statute, regulation, or judicial opinion — for interpretive ambiguity: it finds the seams where the people governed by it will later disagree about what it means and turns each into a concrete dispute scenario with both sides' arguments, the likely outcome, and a fix. Use it whenever someone wants to pressure-test, red-team, audit, or find weak spots, loopholes, gaps, ambiguities, or drafting problems in a legal document; whenever a drafter wants to tighten a contract, statute, regulation, or opinion before it issues; whenever a litigator wants to mine an opinion or contract for arguments; or whenever someone hands over a legal text and asks where it will be fought over or for issue-spotting. Trigger it for contract review, statutory-ambiguity analysis, judicial-opinion scope analysis, and drafting QA — even if the user never says "stress-test" or "ambiguity."
日本語の概要は準備中です。原文の説明を表示しています。