Checklist
Cyber Security Risk Assessment Checklist
A risk assessment checklist turns methodology into execution. This page is the working companion to our comprehensive security risk assessment guide — a sequenced, trackable list of every action item from scoping through post-assessment follow-through. Use it to run your own assessment without skipping the steps that turn findings into action, or hand it to your assessor as the minimum-completeness standard for the engagement.
What this checklist covers
This is a cybersecurity risk assessment checklist — a sequenced set of action items that walks an assessment team from scope definition through post-assessment follow-through. Whether you're running the assessment internally, managing an external assessor, or preparing for your first security risk assessment as a growth-stage company, the checklist ensures nothing material gets skipped.
The checklist is structured in four phases: pre-assessment preparation, assessment execution, deliverables verification, and post-assessment follow-through. Each phase builds on the previous one — skip the pre-assessment scoping and the execution phase produces findings without business context; skip the deliverables check and you get a report without a treatment plan; skip post-assessment and the risk register gathers dust until the next audit cycle.
For the full methodology behind each phase — frameworks compared, qualitative vs quantitative approaches, common mistakes, and cost benchmarks — see the Security Risk Assessment: Complete Guide. This page is the operational companion: the checklist you print, assign, and track.
If you're looking for how this fits into broader governance, risk, and compliance (GRC) operations, the risk assessment checklist is the execution layer beneath your cybersecurity governance framework.
Pre-assessment checklist
The pre-assessment phase defines what you're assessing, who's involved, what framework you'll use, and what resources are available. Rushing past this phase is the most common reason assessments produce technically accurate findings with no business context — making them impossible to prioritize. Every item here should be completed before scanning a single system.
Scope definition
Define assessment boundaries: which business units, systems, data types, and third-party relationships are in scope
Document what is explicitly out of scope and the rationale for each exclusion
Identify regulatory drivers that mandate specific scope elements (HIPAA, PCI-DSS, SOX, GLBA, GDPR, state privacy laws)
Confirm whether cloud environments (AWS, Azure, GCP) are in scope — including IaaS, PaaS, and SaaS layers
Determine whether third-party / supply-chain risk is in scope or deferred to a separate assessment
Document the triggering event: annual cadence, regulatory requirement, pre-acquisition, post-incident, or environment change
Stakeholder identification
Identify the executive sponsor (typically CISO, CTO, or CEO at smaller companies) who owns the assessment outcome — companies without a full-time CISO often engage a fractional CISO to lead the assessment
Map business owners for each critical system — the people who know the business value, not just the technical configuration
Schedule structured interviews with asset owners (15 minutes per system: what data, what happens if down 24 hours, worst-case exfiltration scenario)
Identify the risk owner for each scope area — the person accountable for treatment decisions, not just the person who runs the scan
Confirm board or audit committee reporting requirements and the format they expect
Asset inventory preparation
Compile or verify the existing asset inventory (servers, endpoints, cloud accounts, SaaS applications, network infrastructure)
Identify where regulated data lives: PII, PHI, payment card data, intellectual property, customer credentials
Map data flows between systems — especially flows that cross trust boundaries (internal-to-cloud, vendor-to-production, dev-to-prod)
Tag each asset with its business criticality classification (use a 3-tier minimum: critical, important, standard)
Document which business processes depend on which systems — a compromised HR system and a compromised payment system have different business impacts
If no asset inventory exists, flag this as the first deliverable of the assessment itself
Framework selection and timeline
Select the primary assessment framework: NIST SP 800-30, ISO 27005, CIS RAM, or OCTAVE (see framework comparison)
Decide whether to layer FAIR-based quantitative analysis on top-tier risks (recommended for board-level reporting)
Establish the assessment timeline: 4–6 weeks for focused scope, 8–12 weeks for comprehensive enterprise assessment
Allocate internal resources: security team hours, business-owner interview time, IT support for scanning access
If using an external assessor, confirm their methodology, deliverables, and timeline in writing before engagement starts
Set the risk appetite threshold that will determine which risks require treatment vs acceptance
Assessment execution checklist
The execution phase follows the six-step process documented in the complete guide. Each step below includes the specific action items that constitute thorough execution. The sequence matters — each step depends on the output of the previous one.
Asset identification and classification
Complete the asset inventory for all in-scope systems, including shadow IT discovered during the process
Classify each asset by data sensitivity (public, internal, confidential, restricted)
Assign a dollar value or value range to each critical asset — based on revenue impact, regulatory liability, and replacement cost
Verify asset ownership: every asset has a named business owner, not just a technical administrator
Document interconnections and dependencies between assets (if System A goes down, what else breaks?)
Threat identification
Build a threat catalog specific to your industry, size, and profile — not a generic list of "nation-state actors"
Map threats to MITRE ATT&CK techniques for structured analysis
Review industry-specific threat intelligence reports for the last 12 months
Analyze your own incident history and near-misses from the last 24 months
Include insider threat scenarios — privileged employees, contractors with system access, departing staff
Cross-reference threats against CISA's Known Exploited Vulnerabilities catalog for active exploitation data
Vulnerability analysis
Run automated vulnerability scans across all in-scope systems (Nessus, Qualys, Rapid7, or OpenVAS)
Perform configuration review against CIS Benchmarks or cloud-provider security best practices
Review cloud IAM posture: over-permissive roles, public storage buckets, exposed service accounts
Check process and control gaps: missing MFA, no off-boarding process, unencrypted backups, no IR plan
Review application-layer vulnerabilities if custom applications are in scope (OWASP Top 10, secure SDLC gaps)
Assess third-party and supply-chain vulnerabilities for critical vendors
Map each vulnerability to the assets from the asset identification phase
Control evaluation
Document existing security controls for each risk area (preventive, detective, corrective)
Evaluate control effectiveness — does the control actually reduce the risk it's supposed to, or is it checkbox compliance?
Identify control gaps: areas where no control exists for a documented threat/vulnerability pair
Review security tooling coverage: EDR, SIEM, identity provider, vulnerability management, email security, DLP
Verify that controls are operating as designed (test, don't assume — review logs, run tabletop scenarios)
Assess security awareness program effectiveness: phishing simulation results, training completion rates
Risk analysis
Combine threat and vulnerability data against asset context to produce a risk estimate for each finding
Apply qualitative ratings (likelihood x impact on a consistent scale) across all findings for initial triage
Identify the top 10–15 risks that require quantitative (FAIR-based) analysis
For quantified risks, model annual loss expectancy (ALE) using calibrated frequency and magnitude estimates
Document the assumptions behind each risk rating — these will be challenged during review and must be defensible
Factor in existing controls when estimating residual risk — a vulnerability behind strong compensating controls is different from an uncontrolled one
Risk evaluation and prioritization
Rank all risks by combined risk score (qualitative) or annual loss expectancy (quantitative)
Plot high-level risks on a likelihood-vs-impact matrix for executive communication
Assign a risk owner to each finding — not the person who discovered it, the person accountable for the treatment decision
Select treatment strategy for each risk: mitigate, transfer, accept, or avoid
For accepted risks, document the acceptance rationale and get sign-off at the appropriate authority level
Sequence treatment priorities: which risks must be addressed first based on exposure, regulatory deadlines, or business impact?
Deliverables checklist
A completed security risk assessment produces five deliverables. If any are missing, the assessment is incomplete — you have findings without a pathway to action. Use this section to verify completeness whether you're running the assessment internally or evaluating an external assessor's output.
Risk register
Every identified risk has a finding description written in business terms, not just technical jargon
Each finding includes affected assets and systems mapped from the asset inventory
Likelihood rating (qualitative) or loss-event frequency estimate (quantitative) is documented for each risk
Impact rating (qualitative) or loss magnitude in dollars (quantitative) is documented for each risk
Combined risk score or annual loss expectancy is calculated
A named risk owner is assigned to every finding
Recommended treatment (mitigate, transfer, accept, avoid) is specified for each risk
Existing controls that partially address the risk are documented
Executive summary
Summary is 2–4 pages maximum — concise enough for board members and C-suite who won't read the full register
Overall risk posture is stated clearly (not buried in qualifications)
Top 5 risks are highlighted with business-language descriptions
Investment required to address top risks is quantified with dollar ranges
Comparison to previous assessment is included if one exists (trending better, worse, or flat)
Treatment plan
Each treatment includes specific remediation actions — concrete steps, not "improve security posture"
Timeline and milestones are set for every treatment
Resource requirements are documented: headcount, budget, tools needed
A responsible owner is assigned to each action item (not just the risk owner — the person doing the work)
Expected risk reduction is estimated for each treatment (what does the residual risk look like after completion?)
Dependencies between treatments are identified (some treatments require other treatments first)
Residual risk statement
Residual risk after all planned treatments is documented explicitly
Each accepted risk has documented rationale for acceptance
Residual risk statement is reviewed and signed off by leadership (CISO, risk committee, or board)
Residual risk is expressed in terms the board can act on — ideally dollars, not just ordinal ratings
Trend comparison
New risks that emerged since the last assessment are identified
Previously identified risks that were successfully treated are documented
Risks that worsened since the last assessment are flagged with explanation
Overall posture trend direction is stated: improving, stable, or degrading
If this is the first assessment, note that trend comparison begins with the next cycle
Post-assessment checklist
The assessment itself is a point-in-time snapshot. Without post-assessment follow-through, the risk register becomes another compliance artifact that gathers dust until the next audit cycle. This phase turns findings into operational change.
Treatment tracking
Import every treatment into the organization's project management system — each treatment becomes a ticket with an owner, deadline, and status
Establish a treatment-completion reporting cadence (monthly for active treatments, quarterly for the full register)
Define escalation criteria: what happens when a treatment misses its deadline or the risk owner changes?
Track treatment effectiveness — after implementation, verify that the control actually reduced the risk as expected
Quarterly review cadence
Schedule quarterly risk register reviews — even between full annual assessments
Review treatment completion status and update risk scores based on completed mitigations
Assess whether new threats, incidents, or environment changes warrant risk-score adjustments
Update the executive summary with current posture for board or audit committee reporting
Report treatment metrics to leadership: percentage completed on time, percentage overdue, new risks added
Re-assessment triggers
Document the triggers that require a targeted re-assessment before the next annual cycle
Acquisition or merger (target or acquirer) — new systems, data, and regulatory obligations enter scope
Major cloud migration or infrastructure change — the asset inventory and control landscape shifts
Significant security incident — the threat model and control effectiveness assumptions may be invalidated
New regulatory requirement — HIPAA, PCI-DSS, state privacy law, or industry-specific mandate entering scope
Major application launch or product change — new attack surface and data flows
Stakeholder communication
Deliver the executive summary to the board or audit committee within 30 days of assessment completion
Brief business owners on findings relevant to their systems and the treatment plan
Communicate accepted risks to leadership with explicit sign-off documentation
Share relevant findings with the cyber insurance broker for policy review and renewal preparation
Continuous monitoring setup
Configure vulnerability management tools to continuously monitor for new vulnerabilities on in-scope assets
Set up cloud security posture monitoring (CSPM) for configuration drift detection
Establish alerting thresholds that trigger re-assessment of specific risk register items
Integrate continuous monitoring output into the quarterly review process
Consider unified security platforms that feed vulnerability, posture, and risk data into a single dashboard
Customizing the checklist by industry
The checklist above is framework-agnostic and applies to any organization running a security risk assessment. But regulatory requirements, data types, and threat profiles differ by industry — and the checklist should reflect those differences. Below are the industry-specific additions that supplement the universal checklist.
Healthcare (HIPAA)
Conduct a HIPAA Security Risk Analysis as a documented component of the assessment (45 CFR 164.308(a)(1))
Map all electronic protected health information (ePHI) flows — including to business associates, cloud services, and analytics platforms
Verify Business Associate Agreements (BAAs) are current for every vendor that touches ePHI
Assess breach notification readiness: can you notify HHS and affected individuals within the 60-day HIPAA window?
Review physical safeguards for systems that store or process ePHI (workstation use, facility access controls)
Document the previous HIPAA risk analysis and confirm findings were addressed — auditors check this
Financial services (SOX, PCI-DSS, GLBA)
Scope SOX IT General Controls (ITGCs) for systems that support financial reporting
If payment card data is processed, verify PCI-DSS scope and include cardholder data environment (CDE) in the assessment
Assess GLBA Safeguards Rule compliance: risk assessment is an explicit requirement under the rule
Review NYDFS Part 500 cybersecurity requirements if operating in New York (penetration testing, CISO appointment, incident notification)
Include FFIEC Cybersecurity Assessment Tool alignment if subject to federal banking examination
Document segregation of duties controls for financial systems and privileged access management
SaaS and technology (SOC 2)
Map risk assessment findings to SOC 2 Trust Services Criteria (CC3 — Risk Assessment) for audit readiness
Include multi-tenant isolation as a specific risk category — verify that tenant data cannot cross boundaries
Assess secure SDLC practices: code review, dependency scanning, secrets management, CI/CD pipeline security
Review API security posture: authentication, rate limiting, input validation, logging
Evaluate customer-facing security features: SSO support, audit logging, data export/deletion capabilities
If pursuing SOC 2 Type II, confirm that the risk assessment documentation meets the assessor's evidence requirements
Government and defense (FedRAMP, CMMC)
Align the assessment with NIST SP 800-53 controls at the appropriate impact level (Low, Moderate, High)
If pursuing FedRAMP authorization, document the assessment as part of the System Security Plan (SSP)
For CMMC compliance, verify that the assessment covers all practices at the target maturity level
Include Controlled Unclassified Information (CUI) handling as a specific scope element if applicable
Assess supply-chain risk in accordance with NIST SP 800-161 (supply chain risk management)
Verify that the assessment meets the continuous monitoring requirements of the applicable authorization framework
Want expert-led assessment instead of DIY?
vCSO.ai conducts risk assessments grounded in FAIR methodology — from scope definition through quantified risk register and board-ready executive summary. Nick Shevelyov, former 15-year Chief Security Officer at Silicon Valley Bank, leads every engagement with the same assessment methodology used to protect the bank of the innovation economy.
Request a consultation to scope your assessment, or explore Theodolite — vCSO.ai's unified security platform where risk assessment findings feed the same FAIR-based dollar-risk model that drives vulnerability management, CSPM, and cyber risk quantification.
Nick's book on cybersecurity strategy, Cyber War...and Peace, covers risk assessment methodology, board-level cyber governance, and building security programs that survive the transition from startup to enterprise.
Questions & answers
What is a cyber security risk assessment checklist?
A cyber security risk assessment checklist is a structured working document that walks an organization through every phase of a risk assessment — from scoping and stakeholder identification through assessment execution, deliverables, and post-assessment follow-through. It ensures nothing material gets skipped, regardless of who runs the assessment. The checklist doesn't replace methodology (NIST SP 800-30, ISO 27005, FAIR); it operationalizes methodology into discrete, trackable action items that a team can assign, sequence, and verify.
How do I customize a risk assessment checklist for my industry?
Start with the universal checklist (the one on this page covers the full assessment lifecycle), then layer industry-specific regulatory requirements on top. Healthcare adds HIPAA Security Risk Analysis items and PHI data-flow mapping. Financial services adds GLBA, SOX IT controls, and PCI-DSS scoping. SaaS companies add SOC 2 control mapping and multi-tenant isolation checks. Government contractors add FedRAMP/FISMA/CMMC requirements. The structure stays the same; the regulatory overlay and evidence requirements change by sector.
How often should I run through a cybersecurity risk assessment checklist?
Full checklist execution annually at minimum — this is what most regulatory frameworks (NIST, ISO 27001, PCI-DSS, HIPAA) require. Between annual assessments, run targeted checklist sections whenever the environment changes materially: after an acquisition, a cloud migration, a major application launch, a significant incident, or a change in threat landscape. The post-assessment section of the checklist includes quarterly review cadence items that keep the risk register current between full runs.
What is the difference between a risk assessment checklist and a risk assessment template?
A checklist is a sequenced list of action items to complete — it tells you what to do and in what order. A template is a document structure for capturing results — it tells you how to format the output (risk register columns, executive summary sections, treatment plan fields). You need both. The checklist drives the process; the template captures the findings. This page is the checklist. The companion guide covers the methodology and deliverable structure that functions as the template.
Can a small company use this checklist without a dedicated security team?
Yes, with adjustments. The checklist is structured so that a non-security operator (CTO, VP Engineering, IT Director) can follow it sequentially. For companies without dedicated security staff, the pre-assessment phase is especially critical — it forces the scoping decisions that prevent the assessment from expanding beyond what the team can execute. Items that require specialized tooling (vulnerability scanning, penetration testing, threat intelligence) can be outsourced to a fractional CISO or assessment firm while the internal team handles the business-context items (asset valuation, data classification, stakeholder interviews).
What tools do I need to execute this checklist?
At minimum: a vulnerability scanner (Nessus, Qualys, Rapid7, or OpenVAS for budget-constrained teams), a cloud security posture management tool if you run cloud infrastructure, a GRC or spreadsheet for tracking checklist items and the risk register, and access to threat intelligence feeds (CISA KEV catalog is free and essential). For quantitative analysis on top-tier risks, you'll need a FAIR-based tool or a calibrated spreadsheet model. Theodolite integrates vulnerability management, CSPM, and FAIR-based risk quantification into a single platform if you want to consolidate.
How do I know when the assessment is actually complete?
The deliverables checklist section answers this directly. The assessment is complete when you have five artifacts: (1) a risk register with every finding scored, owned, and treatment-assigned; (2) an executive summary translating top risks into business language; (3) a treatment plan with specific actions, timelines, and responsible owners; (4) a residual risk statement documenting the risk you're choosing to accept; and (5) a trend comparison to the previous assessment if one exists. If any of those five are missing, the assessment is incomplete — you have findings without a pathway to action.
Ready to turn this into a working plan?
Nick's team helps growth-stage companies, PE/VC sponsors, and cybersecurity product teams translate security questions into board-ready decisions. First call is strategy, not vendor pitch.
