This article gives you one working checklist covering cybersecurity, application security, physical and facility security, and remote-access controls, plus a way to prioritize what it finds. It's built for IT managers, risk owners, and business owners who need to run or verify an audit without hiring a consultant to translate the framework first. Use the sections below, collect the evidence each item calls for, and turn your findings into a scored risk register before you call it done.
TL;DR:
- Small teams should prioritize high-impact, high-likelihood findings such as unpatched internet-facing systems or exposed admin ports for immediate remediation.
- Regularly update the risk register to assign clear ownership, realistic deadlines, and evidence for each finding to effectively convert issues into actionable fixes.
- Use automated scans to identify technical weaknesses but always evaluate their business impact and risk before including them in remediation plans.
- Conduct annual full audits with targeted re-checks after major changes and quarterly spot-checks on critical controls like MFA coverage.
- Outsourcing to a managed provider can streamline the process by producing a prioritized, owned remediation plan instead of relying on internal teams to translate vulnerabilities into business risk.
Table of Contents
- How to Use This Security Assessment Checklist
- Cybersecurity Assessment Checklist
- Application Security Checklist
- Physical and Facility Security Checklist
- Telework and Remote Access Security Checklist
- How to Score and Prioritize Findings
- Turning Findings Into Remediation That Sticks
- Templates and Tools to Run Your Own Audit
- Why Business Risk Belongs in Every Security Checklist
- Get a Managed Assessment Instead of a Backlog of Findings
- Sources
- FAQ
How to Use This Security Assessment Checklist
Before you check a single box, define what you're actually assessing. Is this one application, a single office, or the whole company? Set that scope and a time horizon (this quarter's snapshot, or a rolling annual review) before you start, because a checklist run against the wrong boundary produces findings nobody can act on.
Every item needs an owner with the authority to fix it or escalate it. Assigning "IT" as the owner for a physical door lock issue guarantees it never closes.
Collect evidence as you go, not after. Useful evidence types include:
- Configuration exports (firewall rules, MFA policy screenshots)
- Time-stamped log excerpts
- Scan reports from vulnerability tools
- Photos of physical controls, labeled and dated
Cadence matters as much as coverage. A reasonable rhythm looks like this:
- Run a full audit annually across every domain in this checklist.
- Trigger a targeted re-check after any major change: new office, new vendor, security incident, or system migration.
- Spot-check high-risk items (MFA coverage, backup restores) quarterly.
- Feed every finding into a risk register entry with a likelihood/impact score, owner, and deadline, as described in NIST IR 8286.
Skipping the register step is the most common failure. A checklist with 40 checkmarks and no risk register is a snapshot, not a security program.
Cybersecurity Assessment Checklist
Organize your cyber checklist around the five functions in CSF 2.0: Identify, Protect, Detect, Respond, and Recover. That structure keeps an audit from turning into a random grab bag of tool screenshots.
Identify: Pull your asset inventory from at least two sources (an RMM tool and your network scanner) and reconcile the differences. Anything found by the scanner but missing from the inventory is a real finding.
Protect:
- MFA enforced on all privileged and remote accounts, verified by policy export, not a claim
- Privileged roles reviewed recently, with a documented list of who has admin rights and why
- Endpoint detection and response (EDR) installed and reporting on every device, not just servers
- Patch status verified from a management console showing current OS and application versions
- Network segmentation confirmed between guest, production, and admin VLANs, with firewall rule exports as evidence
- External exposure checked with an internet-facing port scan
Detect: Confirm logging coverage extends past firewalls to endpoints, identity systems, and cloud apps. If a SIEM or log aggregator is in place, pull evidence of alert volume and average time-to-acknowledge.
Recover: Verify backups follow the 3-2-1 rule (three copies, two media types, one offsite), confirm at least one copy is encrypted, and require a recent restore test log, not just a completed backup job.
Vendor access: Every third party with system access should appear on a list with the access level, last review date, and an offboarding record showing access was pulled when the engagement ended.
Pro Tip: A scan report is not a risk assessment. Vulnerability scans find technical weaknesses, but someone still has to weigh each finding against business impact before it earns a place on your remediation plan.
Application Security Checklist
Application audits start with an inventory that includes data flow, not just a list of app names. Know what data each application touches, where it's stored, and which third parties can reach it.
Run through these checks for each application in scope:
- Authentication uses MFA where supported, and session timeouts match the sensitivity of the data
- Authorization follows least privilege, with role assignments reviewed on a set schedule
- Secrets (API keys, database credentials) live in a secrets manager, not in code or config files, and rotate on a documented schedule
- Dependencies are scanned with a software composition analysis (SCA) tool, with patch evidence tied to each flagged package
- CI/CD pipelines separate build, staging, and production environments, and signed artifacts prevent unverified code from deploying
- Input validation and output encoding checks follow OWASP-style guidance for injection and cross-site scripting risks
- Telemetry (application logs, error tracking) is retained long enough to support an incident investigation
A built for SEO purposes can double as a starting template for capturing configuration and hardening details, since much of the discovery work overlaps.
Pro Tip: Ask for the CI/CD pipeline configuration, not a verbal description of it. Teams routinely believe their environments are segregated until you look at the actual deployment permissions.
Physical and Facility Security Checklist
Physical audits reward legwork. Walk the perimeter and photograph every entry point, fence line, and unlit corner rather than relying on a floor plan from three years ago.
- Access control: Test whether badge readers, keypads, and mechanical locks actually restrict entry, and confirm the badge list matches current staff.
- Visitor and offboarding process: Check that visitor logs exist and that terminated employees' badges were deactivated within a defined window, not "eventually."
- Locks and barriers: Inspect for maintenance records; a barrier that's never been serviced is a liability, not a control.
- CCTV: Verify camera placement covers actual entry and asset points (not just hallways), confirm the retention policy meets your compliance needs, and test for tamper resistance.
- Alarm and intrusion detection: Pull maintenance logs and, where possible, request evidence of a recent performance test rather than trusting that the panel is "probably fine."
- Support systems: Confirm UPS and generator systems keep access control and cameras running during a power outage. A security system that fails when the power does is not a security system.
The DOE Physical Security Systems Assessment Guide recommends checking for complementary sensor types rather than layering redundant sensors of the same kind, since duplicate technology creates false confidence without covering the gap a different sensor type would catch. For smaller sites weighing new access hardware, a small business access control guide covers installation basics worth reviewing before you buy.
Telework and Remote Access Security Checklist
NIST SP 800-46r2 starts from the assumption that any network outside your control is hostile. Design remote access accordingly.
- Confirm remote access servers (VPN concentrators, RDP gateways) sit in a segmented network zone, inspected separately from internal traffic. Our guide on remote desktop security covers the specific misconfigurations that lead to ransomware entry.
- Verify network access control (NAC) is enforcing device health checks before granting access, not just checking a username and password.
- Confirm a tiered access model separates BYOD from company-owned devices, with BYOD getting narrower access to sensitive systems.
- Test that conditional access policies and MFA apply to every remote session, including mobile.
- Pull connection logs and device health check records as evidence the controls are actually running, not just configured.
Pro Tip: If you can't produce a health check log on request, the control probably isn't enforced. Configured and enforced are two different states, and audits exist to tell them apart.
How to Score and Prioritize Findings
Not every finding deserves the same urgency, and treating them all equally is how remediation plans stall. Score each finding by likelihood times impact, using either a simple High/Medium/Low scale or a numeric one (1 to 5 on each axis, multiplied for a total score).
- Write each finding as a risk scenario: which asset, which threat, which vulnerability, and what the impact would be if it played out. "The file server has no MFA, and a phished credential could expose customer records" is a risk scenario. "MFA is off" is not.
- Score likelihood and impact separately, then multiply for a priority score.
- Set triage thresholds in advance. A missing MFA on an admin account with domain-wide access should trigger an immediate fix, typically within days. A missing restore test on a low-value backup can often wait 30 to 90 days.
- Log every scored finding in a risk register with the asset, scenario, score, owner, status, and evidence link, following the structure NIST IR 8286 recommends for connecting cybersecurity risk to enterprise decision-making.
Where to start when resources are tight: CISA's Cybersecurity Performance Goals prioritize a subset of CSF outcomes by cost and impact, which gives small teams a shortcut when everything on the list looks urgent. Start there instead of trying to close every finding at once.
Turning Findings Into Remediation That Sticks
A scored finding that never gets fixed is just a well-organized problem. Assign a real owner and a realistic deadline for each item, sorted into immediate, 30-day, and 90-day buckets.
- Immediate bucket: anything with high likelihood and high impact, such as an exposed admin port or a missing patch on an internet-facing system
- 30-day bucket: moderate-risk items with a known fix, like enabling MFA on remaining accounts
- 90-day bucket: lower-risk items or fixes requiring budget or vendor coordination, like replacing aging access-control hardware
Verification evidence should match the fix: a rerun scan report for a patched vulnerability, a photo for a repaired lock, a signed change ticket for a firewall rule update. Communicate changes through a change-control process so a "fix" doesn't introduce a new outage.
Pro Tip: If your remediation list has more than a handful of immediate items and no internal capacity to close them fast, that gap is itself a finding. A managed provider can often close a backlog of urgent items in weeks rather than the months an internal team squeezes in between other work.
Templates and Tools to Run Your Own Audit
A working template needs three parts: the checklist itself, a risk register with scoring columns, and a place to log evidence file names against each finding. Keep it simple enough that a team of three can maintain it without a dedicated GRC platform.
- Checklist: organized by domain (cyber, app, physical, telework), one row per control
- Risk register snippet: asset, threat, vulnerability, likelihood, impact, score, owner, status
- Evidence log: file name, date, linked finding ID
| Tool type | What it's good for | What it can't do |
|---|---|---|
| Vulnerability scanner | Finds technical weaknesses fast | Can't judge business impact |
| SCA tool | Flags outdated/vulnerable dependencies | Doesn't test app logic |
| Log aggregator | Centralizes evidence for detection checks | Needs a human to interpret alerts |
Scans and automated tools generate raw findings, but someone still has to interview staff, review documentation, and weigh business context before those findings become a real risk register.
Why Business Risk Belongs in Every Security Checklist
The checklist above only earns its keep once someone connects a finding to what it would actually cost the business. A missing MFA setting isn't the risk. A finance employee's credentials being phished and used to redirect a vendor payment is the risk. That reframing changes who gets pulled into the fix and how fast it happens.
Smaller teams should expect trade-offs. You will not close everything in the immediate bucket the same week you find it, and automating scans buys you coverage, not judgment. Where I see the biggest gap is teams that run a technically thorough audit, then let the findings sit because nobody owns the translation from "vulnerability" to "board-level risk." A managed provider earns its cost by compressing that translation and the remediation backlog into weeks instead of quarters.
, Dustin Collett
Get a Managed Assessment Instead of a Backlog of Findings
A managed provider can turn this checklist into a done-for-you process: a NIST-aligned cybersecurity risk assessment that produces a scored, owner-assigned remediation plan instead of a spreadsheet you have to translate yourself.
Businesses in regulated environments, or teams too stretched to chase down evidence across a dozen systems, tend to get more value from a managed assessment than from running the checklist solo. It's faster, and someone with the framework knowledge is already doing the scoring. If you want a lighter starting point first, our Free IT Risk Score gives you a 60-second diagnostic before committing to a full engagement. When you're ready for the deeper version, our cybersecurity risk assessment covers the same domains this checklist walks through, backed by a team that closes the findings, not just lists them. Request an assessment and get a prioritized remediation plan instead of another unowned spreadsheet.
Sources
- The NIST Cybersecurity Framework (CSF) 2.0
- NIST IR 8286: Integrating Cybersecurity and Enterprise Risk Management
- CISA Cybersecurity Performance Goals (CPGs)
FAQ
What Should a Security Assessment Checklist Cover?
A complete checklist covers cybersecurity controls, application security, physical and facility security, and remote access, each mapped to evidence you can verify rather than a checkbox based on memory.
How Often Should I Run a Security Audit Checklist?
Run a full audit annually, with event-driven checks after major changes like a new office or system migration, and quarterly spot-checks on high-risk items like MFA coverage.
What's the Difference Between a Vulnerability Scan and a Full Assessment?
A vulnerability scan finds technical weaknesses, while a full assessment adds interviews, documentation review, and business context to turn those weaknesses into a prioritized, owned risk register.
How Do I Prioritize Findings From a Security Checklist?
Score each finding by likelihood times impact, then sort results into immediate, 30-day, and 90-day remediation buckets with a named owner for each item.
Can a Managed IT Provider Run This Checklist for Me?
Yes. Some managed IT providers offer NIST-aligned cybersecurity risk assessments that run this checklist end-to-end and convert findings into an owned remediation plan.