Cyber Diligence Governance

Cyber Diligence & Governance

When to Use

• Scope and run M&A or investment cyber diligence on a target or portfolio company
• Plan vendor and third-party security assessments (onboarding, renewal, concentration)
• Review security questionnaires (SIG, CAIQ, custom) and map answers to evidence
• Perform control maturity and gap analysis for diligence or governance (not full audit)
• Assess integration and transition risk (identity, data, tooling, contracts, talent)
• Prepare investment committee, deal team, or board cyber briefs with red flags and asks
• Design ongoing security governance cadence (committee packs, exception reviews, metrics)
• Coordinate diligence workstreams with legal, IT, HR, and product without owning closing

When NOT to Use

• Execute authorized penetration tests or exploit validation → penetration-tester, web-pentester, network-pentester
• Classify AI use cases, model cards, or AI vendor data terms → ai-risk-governance
• Maintain enterprise risk registers, FAIR scoring, or risk appetite without deal/vendor lens → security-risk-analyst
• Stand up GRC programs, framework scope, or audit walkthrough prep → compliance-specialist
• Automate SOC 2/ISO evidence collection → compliance-engineer
• Negotiate contract redlines, DPAs, or liability terms → commercial-counsel
• Run closing matrix, signatures, funds flow, or data room logistics → transaction-manager
• Deploy IAM, SIEM, EDR, or remediate findings → information-security-engineer
• Define CISO program strategy, risk appetite, or board operating model → chief-information-security-officer
• Lead active incidents or SOC triage → incident-responder, soc-analyst
• Operate standing TPRM intake, scoring, and continuous vendor monitoring → vendor-cyber-risk-analyst

Related skills

Core Workflows

1. Scope and charter

Define diligence or governance boundaries, stakeholders, timeline, and deliverables.

See `references/cyber_diligence_governance_scope.md`.

2. M&A and investment diligence

Request lists, evidence review, finding severity, deal protections, and integration themes.

See `references/ma_and_investment_diligence.md`.

3. Vendor and TPRM assessments

Tier vendors, depth of review, concentration, and renewal triggers.

See `references/vendor_and_tprm_assessments.md`.

4. Questionnaire and evidence review

Consistent answers, evidence pointers, stale-response controls, and SME routing.

See `references/questionnaire_and_evidence_review.md`.

5. Governance cadence and reporting

Committee rhythms, IC/board packs, metrics, and exception governance.

See `references/governance_cadence_and_reporting.md`.

6. Red flags and remediation

Severity rubric, deal terms, integration backlog, and acceptance criteria.

See `references/red_flags_and_remediation.md`.

Outputs

• Diligence scope memo — objectives, in/out of scope, timeline, roles
• Request list and tracker — ID, owner, status, evidence received
• Findings register — severity, evidence, recommendation, owner, target date
• IC or board brief — executive summary, top risks, asks, integration implications
• Vendor assessment summary — tier, gaps, conditions, renewal date
• Integration security backlog — Day 1 / 30 / 90 with dependencies
• Governance pack outline — agenda, metrics, exceptions, decisions needed

Principles

• Evidence over assertions — require artifacts; flag questionnaire-only claims
• Materiality and deal context — prioritize what affects valuation, liability, or integration
• Separate roles — diligence analysis ≠ legal advice ≠ control implementation
• Time-boxed depth — match review intensity to tier, deal stage, and access granted
• Explicit handoffs — route legal terms, AI programs, and engineering fixes to peer skills

When to load references

• Boundaries and RACI → references/cyber_diligence_governance_scope.md
• Target or investment diligence → references/ma_and_investment_diligence.md
• Vendor tiers and TPRM → references/vendor_and_tprm_assessments.md
• SIG/CAIQ and evidence → references/questionnaire_and_evidence_review.md
• Committees and board rhythm → references/governance_cadence_and_reporting.md
• Severity and remediation → references/red_flags_and_remediation.md

Cyber diligence and governance scope

Table of contents

1. Program purpose 2. In scope 3. Out of scope 4. Boundaries vs peer skills 5. Roles and RACI 6. Lifecycle and cadence

Program purpose

Enable informed decisions on cyber risk in transactions and third-party relationships by:

• Structuring diligence so findings are evidence-backed, prioritized, and actionable
• Supporting governance cadence so security posture and exceptions are visible to leadership
• Bridging deal, legal, and engineering without owning closing mechanics or control deployment

This skill covers analysis, synthesis, and governance design—not hands-on testing or tool configuration.

In scope

Out of scope

Boundaries vs peer skills

vendor-cyber-risk-analyst

• Vendor analyst owns: ongoing TPRM operations—intake queues, tiering at scale, questionnaire scoring, continuous monitoring, vendor risk dashboards, renewal/offboarding program execution.
• This skill owns: deal- and investment-weighted diligence (M&A, IC/board packs, integration risk) and governance cadence across transactions and leadership forums; vendor assessment in that context or when procurement needs a diligence-style summary.
• Handoff: Day-to-day vendor assessments and monitoring → vendor-cyber-risk-analyst; M&A target review or IC cyber brief → this skill.

ai-risk-governance

• AI skill owns: model/system documentation, AI use-case tiers, AI acceptable use, AI vendor data/fine-tuning terms, NIST AI RMF / ISO 42001 / EU AI Act–style mapping for AI systems.
• This skill owns: enterprise cyber diligence on a target or vendor as a whole (including AI as one workstream), transaction integration of AI tooling, and board/deal narrative on cyber materiality.
• Handoff: When diligence centers on autonomous agents, training data, or regulated AI products, pull ai-risk-governance for tiering and documentation depth; fold summary into deal findings.

security-risk-analyst

• Risk analyst owns: ongoing risk register, inherent/residual scoring, treatment options, KRIs, and standing third-party risk tiers in the enterprise program.
• This skill owns: time-boxed diligence and governance packs for a specific deal, investment, or vendor event; findings that feed (not replace) the register.
• Handoff: After close or vendor approval, transfer accepted risks and mitigations to security-risk-analyst with owners and review dates.

compliance-specialist

• Compliance owns: audit program, control matrices for attestation, continuous compliance operating model, approved questionnaire library maintenance.
• This skill owns: evaluating third-party or target responses during diligence/procurement; gap themes for deal terms; governance reporting on security posture.
• Handoff: Align questionnaire answers with compliance library where possible; escalate attestation scope changes to compliance-specialist.

Roles and RACI

R = responsible, A = accountable, C = consulted, I = informed. Adjust titles to your organization.

Lifecycle and cadence

Review governance cadence at least quarterly; re-run diligence on material vendor or target changes.

Governance cadence and reporting

Table of contents

1. Governance forums 2. Standing agenda themes 3. Metrics and KRIs 4. IC and board packs 5. Exception and risk acceptance 6. Coordination with CISO and risk analyst

Governance forums

This skill drafts content for these forums; chief-information-security-officer owns executive operating model and board relationship norms.

Standing agenda themes

Rotate focus to avoid static status slides:

1. Posture snapshot — top strengths and gaps vs prior quarter 2. Diligence pipeline — active M&A, major vendor assessments, status 3. Incidents and near-misses — material events, lessons, open actions 4. Program progress — remediation burndown, audit themes (high level) 5. Third-party risk — tier changes, concentration, expired certs 6. Integration — post-close backlog health (Day 30/90) 7. Decisions needed — exceptions, funding, policy exceptions

Keep compliance attestation narrative separate from risk and diligence narrative to avoid conflating audit readiness with deal risk.

Metrics and KRIs

Examples (tailor to organization):

Pair activity metrics with outcome metrics where possible. Detailed KRI design → security-risk-analyst and chief-information-security-officer.

IC and board packs

Structure for deal or standing cyber brief:

1. Executive summary (≤1 page) — decision or ask 2. Context — deal/vendor/target, scope, access limitations 3. Top findings (3–7) — severity, evidence, business impact 4. Red flags — show-stoppers vs manageable gaps 5. Remediation / integration — cost, timeline, owners 6. Recommendations — proceed, conditions, pause, further diligence 7. Appendix — request tracker, detailed register (optional)

Use consistent severity labels across diligence and governance (see references/red_flags_and_remediation.md).

Avoid jargon walls; define acronyms once. Do not include privileged legal analysis without counsel review.

Exception and risk acceptance

For governance-approved exceptions (tooling, architecture, vendor):

Expired exceptions surface as standing agenda items. Transfer standing risks to security-risk-analyst register.

Coordination with CISO and risk analyst

Cyber diligence lead feeds risk analyst and CISO with transaction-specific findings; does not duplicate enterprise-wide register maintenance unless chartered.

M&A and investment diligence

Table of contents

1. Diligence objectives 2. Workstream setup 3. Request list themes 4. Evidence review 5. Interviews and technical sessions 6. Findings and deal implications 7. Integration planning

Diligence objectives

Clarify upfront:

Align objectives with deal lead and legal; coordinate timing with transaction-manager for VDR and Q&A hygiene.

Workstream setup

1. Charter — scope, exclusions, deliverables, deadline (signing vs close) 2. Access — VDR index, interview list, pen test reports (if available), policies 3. Tracker — request ID, owner, status, evidence link, follow-ups 4. SME map — identity, cloud, appsec, IR, privacy, IT general controls 5. Readout cadence — weekly steering; IC draft milestones

Do not duplicate process ownership held by transaction-manager; provide cyber content for their trackers.

Request list themes

Organize requests by control domain (adjust for target size):

Prioritize material systems and customer data paths. Flag when target cannot produce evidence within timeline.

Evidence review

For each request:

1. Authenticate — date, scope, auditor/tester, version 2. Map — control intent vs artifact (policy alone ≠ operating effectiveness) 3. Test — sample consistency (e.g., access review ticket matches policy cadence) 4. Correlate — breach disclosures, customer churn, insurance claims, litigation mentions 5. Record — finding or clear pass with citation (document, page, date)

Use third-party reports (SOC 2, ISO) as starting points, not substitutes for targeted questions on gaps and incidents.

Interviews and technical sessions

Prepare question trees; avoid leading assertions. Document quotes as attributed notes, not binding representations.

Findings and deal implications

Rate findings (see references/red_flags_and_remediation.md):

Separate fact findings from legal recommendations; route terms to commercial-counsel.

Integration planning

Post-signing themes for security backlog:

Hand engineering execution to information-security-engineer; program narrative to chief-information-security-officer where appropriate.

Questionnaire and evidence review

Table of contents

1. Questionnaire types 2. Review process 3. Evidence standards 4. Consistency and stale answers 5. SME routing 6. Outbound vs inbound

Questionnaire types

Review process

1. Triage — due date, tier, repeating vs net-new, deal sensitivity 2. Assign — cyber diligence lead coordinates; SMEs own sections 3. Answer mapping — map each question to control theme and required evidence 4. Verify — attach evidence or flag “assertion only” 5. Gap list — partial/missing controls with severity 6. Approval — security delegate before external send (outbound) or internal sign-off (inbound summary) 7. Archive — version, date, approver, evidence links for reuse

Evidence standards

Acceptable evidence hierarchy (strongest first):

1. Independent third-party report (SOC 2, ISO) — check period, scope, exceptions, bridge letter 2. Test results — pen test executive summary, vuln scan with remediation status 3. Operational records — tickets, access reviews, change records (sampled) 4. Configuration / architecture — diagrams, screenshots with date and system ID 5. Policy / procedure — necessary but insufficient alone

Reject or downgrade when:

• Report is expired or wrong entity (parent vs subsidiary)
• Scope excludes material services
• Marketing PDF with no auditor or test metadata
• “Planned” or “roadmap” without committed date and owner

Consistency and stale answers

Before reusing library answers (outbound) or trusting target responses (inbound):

Mark answers stale if older than 6 months for critical tier (adjust per policy).

SME routing

Cyber diligence lead integrates SME input into one findings narrative.

Outbound vs inbound

Never state technical controls that engineering has not validated. Route unvalidated claims to information-security-engineer before external submission.

Red flags and remediation

Table of contents

1. Severity rubric 2. Common red flags 3. Deal and procurement responses 4. Remediation planning 5. Acceptance and residual risk 6. Pentest and audit inputs

Severity rubric

Document evidence, affected systems, and business impact for each finding.

Common red flags

Corroborate red flags with evidence; distinguish confirmed vs suspected.

Deal and procurement responses

Coordinate legal mechanisms with commercial-counsel and deal process with transaction-manager. This skill supplies security fact pack and recommended posture, not binding legal advice.

Remediation planning

For each High/Medium finding:

1. Root cause — people, process, technology 2. Remediation action — specific, measurable 3. Owner — named role 4. Target date — aligned to Day 1 / 30 / 90 or vendor contract 5. Verification — how completion is proven 6. Dependency — budget, integration, vendor

Track in shared backlog; review in governance cadence (references/governance_cadence_and_reporting.md).

Acceptance and residual risk

When remediation before close is infeasible:

1. Document residual risk in business terms 2. Define compensating controls and monitoring 3. Obtain risk acceptance per policy with named approver and expiry 4. Register in security-risk-analyst risk register when material

Do not accept Critical findings without executive and legal alignment.

Pentest and audit inputs

Commission new testing via penetration-tester when deal risk justifies fresh validation; incorporate results into findings register.

Vendor and TPRM assessments

Table of contents

1. Assessment triggers 2. Vendor tiers 3. Depth of review by tier 4. Assessment workflow 5. Concentration and fourth parties 6. Renewal and offboarding 7. Alignment with compliance-specialist

Assessment triggers

Run or refresh assessment when:

• New vendor processes sensitive or regulated data
• Production access, source code, or customer-facing dependency
• Material contract (revenue, exclusivity, multi-year)
• M&A introduces new subprocessors
• Incident, breach notification, or certification lapse at vendor
• Change in processing location, subprocessors, or AI/ML use of customer data

Vendor tiers

Document tier rationale in vendor record. Align with compliance-specialist subprocessors list for audit scope.

Depth of review by tier

Escalate to full diligence (M&A-style) when acquiring vendor technology or assuming their infrastructure.

Assessment workflow

1. Intake — business owner, data types, integrations, contract value 2. Tier — apply criteria; security lead confirms 3. Collect — questionnaire, reports under NDA, supplemental questions 4. Analyze — gaps vs baseline; red flags (see references/red_flags_and_remediation.md) 5. Decide — approve, approve with conditions, reject, or escalate 6. Record — assessment date, approver, conditions, re-review date 7. Monitor — cert expiry, breach news, subprocessors change

Legal terms (indemnity, liability, audit rights) → commercial-counsel.

Technical validation (encryption, logging claims) → information-security-engineer or cloud-security-engineer.

Concentration and fourth parties

Track:

• Shared IdP, cloud, CDN, or payment processor across critical vendors
• Fourth parties listed in vendor SOC reports
• Geographic concentration (residency, sanctions exposure — coordinate with legal/compliance)

Report concentration in governance packs when it affects blast radius of a single supplier failure.

Renewal and offboarding

Feed residual vendor risk into security-risk-analyst register when material.

Alignment with compliance-specialist

• Use approved response library and evidence pointers maintained under GRC program where they exist
• Do not invent certification scope; match SOC/ISO report period and trust criteria
• For customer-facing questionnaires (your company as vendor), coordinate outbound responses with compliance-specialist workflow in compliance-specialist/references/vendor_and_continuous_compliance.md
• This skill emphasizes inbound evaluation of others and deal-time depth; compliance-specialist owns program rhythm and audit alignment