NIST Cybersecurity Framework 2.0 for Websites: A Practical SMB Guide
The NIST Cybersecurity Framework is the most widely adopted voluntary cybersecurity standard in the United States, used by organizations ranging from Fortune 500 companies to municipal governments and SMBs. The 2024 update to version 2.0 added a sixth function — Govern — and expanded guidance for small organizations.
Unlike PCI DSS or HIPAA, NIST CSF is not prescriptive. It does not tell you exactly which controls to implement; it gives you a structure for thinking about risk and a common language for describing your security posture. For small and mid-sized businesses, that flexibility is the point: you apply the framework at the level of maturity that is appropriate for your risk profile.
This guide applies all six CSF 2.0 functions to website security in terms that an SMB engineering team can act on today.
Check your compliance posture: Free ZeriFlow security scan →
The Six Functions of NIST CSF 2.0
NIST CSF 2.0 organizes cybersecurity activities into six concurrent and continuous functions:
- 1Govern — Establish and monitor your cybersecurity risk management strategy, expectations, and policies.
- 2Identify — Understand your assets, risks, and business environment.
- 3Protect — Safeguards to ensure delivery of critical services and limit the impact of cybersecurity events.
- 4Detect — Activities to identify cybersecurity events.
- 5Respond — Actions to take regarding a detected cybersecurity incident.
- 6Recover — Activities to restore capabilities impaired by a cybersecurity incident.
These functions are not phases or steps — they operate simultaneously. A mature security program is continuously doing all six.
Govern: Building the Foundation
The Govern function is new in CSF 2.0. It recognizes that technical controls without organizational context are unsustainable — someone must own the security program, define risk tolerance, and ensure accountability.
For an SMB operating a website, Govern translates to:
Define a cybersecurity policy — Even a one-page document that states your commitment to security, your asset classification approach, and your expectations for employees and contractors is sufficient to start.
Assign ownership — Someone must own the security of your web infrastructure. At small companies, this is often the CTO or a senior engineer. The key is that it is explicit — security by diffusion of responsibility means security by neglect.
Define risk tolerance — What are you willing to accept? What would constitute a material security failure? For an e-commerce site, downtime during peak shopping season is high-severity. For a B2B SaaS, a data breach affecting customer data is critical. Defining this in advance shapes how you prioritize the other five functions.
Third-party risk — NIST CSF 2.0 GV.SC (Supply Chain Risk Management) emphasizes understanding and managing security risks from third-party vendors. For websites, this means knowing what vendors have access to your infrastructure or process your user data.
Identify: Knowing What You Have
You cannot protect what you do not know exists. The Identify function covers asset management, risk assessment, and business environment understanding.
Asset inventory for a web-facing organization: - Domain names and DNS records - TLS certificates (and their expiry dates) - Hosting accounts and cloud resources - Third-party services and integrations (analytics, CDN, email, payment processors) - Dependencies in your software stack (libraries, frameworks, plugins)
Risk assessment — For each asset, what are the plausible threats? For a web application: injection attacks, authentication bypass, exposed sensitive endpoints, third-party supply chain compromise, infrastructure misconfiguration. A basic risk assessment maps assets to threats and existing controls, identifies gaps, and prioritizes remediation.
Vulnerability identification — Regular scanning of web-facing assets surfaces configuration gaps before attackers find them. ZeriFlow provides the Identify-function data for your public web infrastructure: TLS posture, security header configuration, DNS security, email authentication, and cookie security — 80+ checks that give you a current-state inventory of your web security posture.
Protect: Implementing Technical Safeguards
The Protect function is where most web security investment goes. For website security, the core protective controls are:
Identity and Access Management (PR.AA) - Unique identifiers for all users and service accounts - Multi-factor authentication on all administrative access - Principle of least privilege for all access - Regular access reviews
Awareness and Training (PR.AT) - Developers trained on OWASP Top 10 - Team aware of phishing and social engineering risks - Secure coding practices documented
Data Security (PR.DS) - TLS 1.2+ enforced on all web endpoints - HSTS to prevent protocol downgrade - Data at rest encrypted - Sensitive data minimization (do not collect or retain data you do not need)
Platform Security (PR.PS) - Security headers deployed (CSP, HSTS, X-Frame-Options, etc.) - Patch management process for OS, web server, frameworks, and dependencies - Web Application Firewall (WAF) deployed for applications handling sensitive data - Secure configuration baselines documented
Technology Infrastructure Resilience (PR.IR) - Backups tested and restorable - DDoS protection at the network/CDN layer - Infrastructure-as-code and configuration management preventing drift
Detect: Finding Problems Before They Become Incidents
The Detect function is chronically underfunded at SMBs. The average time to detect a breach in 2024 was still over 100 days — time during which an attacker has unrestricted access.
Continuous monitoring (DE.CM) for web security: - Uptime monitoring with immediate alerting - Certificate expiry monitoring (alert at 30 days, 14 days, 7 days) - Log monitoring for authentication anomalies (high failure rates, impossible travel, unusual access times) - Web application vulnerability scanning on a defined cadence - Third-party script monitoring (relevant for e-commerce Magecart prevention)
Adverse event analysis (DE.AE): - Define what "normal" looks like for your web traffic so anomalies are recognizable - Integrate vulnerability scanner output with your alerting system - Establish thresholds for human review (X failed logins per hour, Y new 500 errors per minute)
Respond: When Things Go Wrong
The Respond function requires a plan. The worst time to design your incident response is after an incident has started.
Incident response planning (RS.MA): - Document your incident response procedures before you need them - Define severity levels (P0: active data breach, P1: service down, P2: security finding with no evidence of exploitation) - Define escalation paths: who gets called at 2am for a P0? - Define communication procedures: customers, regulators, board
Incident analysis (RS.AN): - Preserve logs before taking any remediation action - Determine scope: what systems were affected, what data was exposed, how long was the access?
Incident mitigation (RS.MI): - Contain the incident: disable compromised accounts, block attacking IPs, take affected services offline if necessary - Remediate the root cause: patch the vulnerability, rotate exposed credentials, fix the misconfiguration
Recover: Restoring Normal Operations
The Recover function is about getting back to business and learning from the experience.
Incident recovery (RC.RP): - Restore services from known-good backups - Verify that the attack vector is closed before restoring service - Document the recovery timeline and actions taken
Incident recovery communication (RC.CO): - Communicate restoration progress to affected customers and stakeholders - For notifiable incidents (GDPR, state breach notification laws), ensure notification timelines are met
Lessons learned: - Post-incident review within two weeks - Update the incident response plan based on what worked and what did not - Update technical controls to prevent recurrence
NIST CSF for SMBs: Where to Start
The biggest trap for SMBs approaching NIST CSF is trying to implement everything at once. The framework is designed for progressive maturity. A practical starting sequence:
- 1Govern: Assign ownership, write a one-page security policy, document your risk tolerance.
- 2Identify: Build your asset inventory. Run an external scan to understand your current web security posture.
- 3Protect: Fix the highest-severity findings from your scan. Implement MFA on all admin access. Enable HSTS. Deploy a WAF if you handle sensitive data.
- 4Detect: Set up certificate expiry alerts. Enable login failure alerting. Schedule recurring vulnerability scans.
- 5Respond: Write a one-page incident response procedure. Define who gets called for a P0.
- 6Recover: Test your backup restoration process. Confirm you can restore your website from backup within your defined RTO.
FAQ
Q: Is NIST CSF legally required?
A: No — NIST CSF is a voluntary framework. However, it is referenced in several regulatory contexts: the SEC's cybersecurity disclosure rules for public companies reference it, CISA recommends it for critical infrastructure, and many federal contractors are required to align with it. For SMBs, the most common driver is customer requirements: enterprise buyers increasingly ask about security frameworks in vendor questionnaires.
Q: How does NIST CSF 2.0 differ from version 1.1?
A: The main addition is the Govern function (version 1.1 had five functions). CSF 2.0 also expanded supply chain risk management guidance (GV.SC), added tiers for the Govern function, and explicitly addressed the needs of smaller organizations. The underlying technical content in Protect, Detect, Respond, and Recover is largely consistent with version 1.1.
Q: What is a NIST CSF "Profile" and do I need one?
A: A Profile is a customization of the framework to your specific organization — mapping the framework's categories to your actual practices and desired state. It is a useful tool for identifying gaps between where you are and where you want to be, and for communicating your security posture to stakeholders. For most SMBs, a simple spreadsheet mapping each category to "Not Started / In Progress / Implemented" is sufficient to get value from the framework without creating unnecessary documentation overhead.
Q: Can NIST CSF prepare us for a formal audit (SOC 2, ISO 27001)?
A: Yes. NIST CSF has published crosswalks to SOC 2, ISO 27001, PCI DSS, HIPAA, and other frameworks. Organizations that implement NIST CSF rigorously find that they have addressed most of the technical controls required by these formal audit standards. CSF is often used as the organizing framework for a compliance program that targets multiple certifications simultaneously.
Q: What tools do SMBs actually need to implement NIST CSF for a website?
A: The minimal useful stack: a vulnerability scanner (for Identify and Detect), MFA on all accounts (Protect), a centralized logging solution (Detect), uptime monitoring (Detect), and backup verification (Recover). For most SMBs with a web application, this means: an external security scanner like ZeriFlow for web posture, Duo or Authy for MFA, a cloud provider's native logging (CloudWatch, GCP Logging), a simple uptime monitor, and regular backup restoration tests.
Conclusion
NIST CSF 2.0 gives SMBs a vocabulary and structure for web security without mandating specific products or configurations. The six functions — Govern, Identify, Protect, Detect, Respond, Recover — map naturally onto the activities a well-run engineering team is already doing or should be doing.
The Identify function is where most SMBs have the largest gap: they have not systematically inventoried their web security posture and do not know what an external attacker sees. Fixing that gap is the fastest way to improve your security posture.