Security Risk Analyst

Security Risk Analyst

When to Use

• Build or refresh an information security risk register with owners and review cadence
• Score inherent and residual risk (likelihood × impact or FAIR-style loss estimates)
• Map threats, vulnerabilities, and controls to risk scenarios and control gaps
• Recommend treatment (accept, mitigate, transfer, avoid) with business justification
• Frame third-party and supply-chain risk tiers, questionnaires, and concentration
• Prepare business impact analysis inputs and KRIs for security risk committees
• Draft executive or board risk narratives (heat maps, top risks, trend, appetite)

When NOT to Use

• Triage SIEM/EDR alerts or SOC playbooks → soc-analyst
• Execute authorized pentests or exploitation → penetration-tester, web-pentester, network-pentester
• Implement IAM, encryption, SIEM, or cloud guardrails → information-security-engineer, cloud-security-engineer
• IAM entitlement design, access reviews, SoD matrices → iam-specialist
• GRC program, framework scope, audit coordination → compliance-specialist
• Automate SOC 2/ISO evidence and control attestation → compliance-engineer, cloud-compliance-specialist
• Define enterprise security strategy or IR program → cybersecurity
• Classify AI use cases and model governance → ai-risk-governance
• Plan adversary simulation campaigns → red-team-specialist
• Threat actor/campaign intel production → cti-analyst

Related skills

Core Workflows

1. Risk assessment intake

1. Define scope (business unit, system, vendor, program) 2. Identify assets, data classes, and dependencies 3. Capture threat events and vulnerabilities (see references) 4. Document existing controls and their effectiveness 5. Score inherent risk (before controls) and residual (after controls) 6. Compare to risk appetite and escalation thresholds

See `references/risk_identification_and_scoring.md`.

2. Risk register maintenance

Maintain one row per material risk scenario:

Review quarterly minimum; re-score on major change, incident, or audit finding.

See `references/security_risk_analyst_scope.md` for boundaries.

3. Threat–vulnerability–control mapping

threat actor/event → vulnerability/condition → impact → existing controls → gap → residual risk

Link pentest, vuln scan, audit, and threat intel inputs without duplicating execution work.

See `references/threat_vulnerability_control_mapping.md`.

4. Treatment and acceptance

For each risk above appetite:

1. Propose treatment option(s) with cost, effort, and residual risk 2. Obtain risk owner and risk committee decision where required 3. Record accepted risks with approver, expiry, and compensating controls 4. Track mitigation tasks to closure; re-score residual on completion

See `references/treatment_and_acceptance.md`.

5. Third-party and supply-chain risk

Tier vendors by data access, criticality, and concentration. Align questionnaire depth to tier. Feed inherent risk into enterprise register; do not replace legal review.

See `references/third_party_and_supply_chain_risk.md`.

6. Reporting and governance

Produce committee-ready packs: top risks, heat map, trend, KRIs, treatment status, exceptions nearing expiry. Separate risk analysis from compliance attestation narratives.

See `references/reporting_and_governance.md`.

When to load references

• Scope and role boundaries → references/security_risk_analyst_scope.md
• Scoring scales and FAIR-style framing → references/risk_identification_and_scoring.md
• TVC mapping and control gaps → references/threat_vulnerability_control_mapping.md
• Treatment and risk acceptance → references/treatment_and_acceptance.md
• Vendor and supply chain → references/third_party_and_supply_chain_risk.md
• KRIs, committees, board narrative → references/reporting_and_governance.md

Reporting and governance

Table of contents

1. Audiences 2. Committee pack structure 3. KRIs 4. Board narrative 5. Risk vs compliance reporting 6. Cadence

Audiences

Tailor language: business impact and decisions, not CVE lists.

Committee pack structure

Recommended sections (≤15 slides or equivalent):

1. Executive summary — posture vs appetite, key changes since last meeting 2. Top risks — residual heat map or ranked table (inherent vs residual) 3. New and closed — scenarios added/retired since last cycle 4. Treatments — on-track / at-risk mitigations; overdue callouts 5. Acceptances — open acceptances nearing expiry; new requests 6. Third party — tier changes, critical vendor issues 7. KRIs — RAG status and commentary 8. Incidents and lessons — link to register updates (no full IR timeline) 9. Decisions needed — acceptances, appetite exceptions, funding asks

Attach register export as appendix; do not read rows aloud in meeting.

KRIs

Define Key Risk Indicators per top scenario or category:

Rules:

• Thresholds aligned to risk appetite (green/amber/red)
• Owner for each KRI (usually control owner, not risk analyst alone)
• KRIs measure risk drivers, not compliance checkbox completion

Board narrative

Board materials should answer:

• Are we within appetite for material cyber risk?
• What changed this quarter (threat, incident, regulation, major project)?
• What investments reduce top residual risks?
• Any accepted risks above normal delegation?
• How do incidents affect the risk profile?

Avoid: raw scan counts, tool logos, uncertified compliance claims. Coordinate with cybersecurity for program context.

Risk vs compliance reporting

Cross-reference: a failed control may increase residual risk; do not duplicate full control matrices in risk packs.

Cadence

After SEV1/SEV2 security incident: ad hoc committee briefing within 10 business days if material to top risks.

Risk identification and scoring

Table of contents

1. Identify scenarios 2. Qualitative scales 3. Inherent vs residual 4. FAIR-style quantitative framing 5. Risk appetite and escalation 6. Common mistakes

Identify scenarios

Write risks as events, not control names:

• Bad: "Missing MFA"
• Good: "Unauthorized access to production via stolen credentials due to absent MFA on admin console"

Sources: threat intel, incidents, pentests, vuln scans, architecture reviews, vendor assessments, regulatory change.

Group duplicates; one register row per material scenario per scope.

Qualitative scales

Default 5×5 likelihood × impact (adjust only with documented org scale):

Inherent score = likelihood × impact before controls. Residual = after controls, with documented control effectiveness (full / partial / none).

Inherent vs residual

1. Score inherent from threat + vulnerability without assuming controls. 2. List existing controls (preventive, detective, corrective). 3. Adjust likelihood and/or impact for effective controls only—cite evidence (config, test, audit). 4. Residual above appetite → treatment required or formal acceptance.

Re-score when: major architecture change, control failure, incident, or audit finding.

FAIR-style quantitative framing

Use when leadership requires loss exposure in currency:

• Loss event frequency (LEF) × loss magnitude (LM) → annualized loss exposure (ALE)
• Decompose LM: primary response, secondary (fines, churn), fines where applicable
• Document assumptions; ranges beat false precision
• Calibrate with historical incidents and industry benchmarks where available

Qualitative heat maps and FAIR estimates may coexist for the same portfolio—label methodology per row.

Risk appetite and escalation

Document organizational appetite (acceptable residual band) per category (e.g., customer data, OT, third party).

Never accept critical residual without named executive approver and expiry.

Common mistakes

• Scoring controls instead of scenarios
• Residual = inherent because controls are "planned" not implemented
• Ignoring concentration (one vendor, one region, one key person)
• Using audit compliance pass as proof of low residual risk without threat context

Security risk analyst scope

Table of contents

1. Purpose 2. In scope 3. Out of scope 4. Framework alignment 5. Deliverables 6. Peer handoffs

Purpose

Analyze information security risk so leaders can prioritize investment, accept residual risk explicitly, and govern third parties—without operating controls, running audits end-to-end, or executing tests.

In scope

• Risk registers, scenarios, inherent/residual scores
• Threat–vulnerability–control (TVC) mapping and gap analysis
• Treatment recommendations and risk acceptance records
• Business impact framing for security scenarios (availability, confidentiality, integrity, safety where relevant)
• KRIs and risk committee / board narrative support
• Third-party and supply-chain risk tiering and questionnaire scope (not legal contracting)

Out of scope

Framework alignment

Use concepts from ISO/IEC 27005 (risk management) and NIST RMF (categorize → select → implement → assess → authorize → monitor) as structure, not as a substitute for organizational risk appetite statements or legal obligations.

• Do map scenarios to assets, threats, controls, and residual risk.
• Do not claim full ISO 27001 certification readiness—that is compliance-engineer with evidence workflows.

Deliverables

Peer handoffs

Third-party and supply-chain risk

Table of contents

1. Tiering model 2. Inherent risk factors 3. Assessment depth 4. Supply-chain extensions 5. Concentration and fourth parties 6. Lifecycle events

Tiering model

Tier vendors before deep assessment:

Align tier with inherent risk in the enterprise register; one vendor may map to multiple scenarios.

Inherent risk factors

Score or tag vendors on:

• Data: PII, PHI, PCI, credentials, source code, AI training data
• Access: Production, network, IdP federation, break-glass
• Criticality: Outage duration if vendor fails
• Substitutability: Switching cost and time
• Geography: Residency, sanctions, political exposure
• Concentration: % of revenue or workloads on one provider

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

Assessment depth

Gap findings become register rows or feed existing rows; assign remediation owner (vendor manager + information-security-engineer for technical gaps).

Supply-chain extensions

Beyond SaaS vendors:

• Software dependencies: SBOM risk themes (unmaintained libs, typosquat)—coordinate with devsecops for pipeline controls
• Hardware / OEM: firmware, support EOL—coordinate with procurement
• Managed service providers: shared tenancy, staffing access
• Open source: license and maintainer risk for embedded components

Risk analyst frames scenario and residual; does not run SCA tools.

Concentration and fourth parties

Flag concentration risk explicitly:

• Single hyperscaler region for all production
• One IdP, one email security vendor, one backup provider
• Subprocessors not disclosed for T1 vendors

Require fourth-party list for T1 contracts where possible; inherit subprocessors into scenario library (e.g., "primary vendor breach via unknown subprocessor").

Lifecycle events

Re-tier or reassess on:

• New data type or production integration
• Acquisition, merger, or hosting change
• Public breach or sustained outage
• Contract renewal (use as forcing function)
• Offboarding: confirm data return/deletion risks until exit complete

Hand legal and privacy questions to counsel; provide risk tier and required clauses list only.

Threat, vulnerability, and control mapping

Table of contents

1. TVC chain 2. Threat sources 3. Vulnerability types 4. Control mapping 5. Gap analysis 6. Integrating test results

TVC chain

Document each material scenario as:

Threat (who/what) → Vulnerability (weakness) → Impact (business) → Controls → Gap → Residual risk

Example:

Threat sources

Use MITRE ATT&CK or CAPEC labels where helpful for consistency; do not duplicate red-team-specialist campaign planning.

Vulnerability types

Link each vulnerability to evidence (scan ID, ticket, audit finding)—not opinion alone.

Control mapping

Map controls to NIST CSF or ISO 27001 Annex A families for portfolio views:

Rate control design (documented) vs operating effectiveness (tested). Partial effectiveness lowers confidence in residual score—do not treat policy-only as full mitigation.

Gap analysis

For each scenario:

1. List required controls per policy or framework target state 2. Compare to current state (evidence) 3. Classify gap: missing, partial, unmonitored 4. Prioritize gaps by residual risk and exploitability

Output: ranked remediation themes for information-security-engineer and evidence needs for compliance-engineer.

Integrating test results

Translate findings into register updates within 10 business days of report delivery.

Treatment and acceptance

Table of contents

1. Treatment options 2. Decision criteria 3. Mitigation plans 4. Transfer and avoid 5. Risk acceptance 6. Re-review triggers

Treatment options

Record one primary treatment per risk; secondary actions in mitigation plan notes.

Decision criteria

Compare options on:

• Residual risk after treatment (re-score)
• Cost (CapEx, OpEx, opportunity cost)
• Time to implement vs regulatory or contract deadline
• Dependencies (other projects, vendors)
• Side effects (UX, availability, technical debt)

Document why rejected options were not chosen for audit and committee readability.

Mitigation plans

Each mitigation task needs:

Escalate overdue high/critical mitigations to risk committee monthly.

Transfer and avoid

Transfer:

• Cyber insurance: confirm coverage matches scenario (ransomware, privacy liability)
• Contracts: security exhibits, SLAs, audit rights—coordinate with legal; risk analyst frames residual after contract controls
• Cloud shared responsibility: inherit provider controls only with cited evidence (cloud-compliance-specialist)

Avoid:

• Decommission system, disable feature, or stop processing sensitive data class
• Update register: status closed or avoided with approver and date

Risk acceptance

Required when residual remains above appetite:

1. Written rationale (business benefit, constraints, compensating controls) 2. Approver at delegated authority level (see governance reference) 3. Expiry date (max 12 months; critical max 6 months) 4. Compensating controls if any (monitoring, manual checks) 5. Link to incident and audit obligations if acceptance fails

Store acceptance in the same system as the risk register; no oral-only acceptances.

Re-review triggers

Re-open treatment or acceptance when:

• Expiry date reached
• Related incident or near-miss
• Material control change or audit failure
• Vendor breach or contract change
• Risk appetite statement updated

Default: full register review quarterly; critical rows monthly until residual within appetite.