Website Security Assessment: What It Covers and How It Maps to NIST CSF 2.0, OWASP and CIS Controls

A website security assessment is a structured check of how well your website, and the systems it depends on, meet a defined set of security objectives. It covers the site itself, the hosting and server software, the CMS and its plugins, admin access and two-factor authentication, backups, third-party scripts, and basic email and DNS settings. The result is a written list of findings, ranked by priority, that someone can act on.

NIST's long-standing definition, in SP 800-115, describes an assessment as "the process of determining how effectively an entity being assessed ... meets specific security objectives," using three methods: testing, examination and interviewing. That last part matters. A good assessment is not just a scan. It also reads configurations and asks the people who run the site how things actually work.

This guide explains what an assessment should cover, how it maps to the frameworks in use as of October 2026 (NIST CSF 2.0, OWASP Top 10:2025, OWASP ASVS 5.0.0, CIS Controls v8.1 and, for card payments, PCI DSS v4.0.1), how it differs from a scan or a penetration test, what you should receive and how to prepare.

What a Website Security Assessment Covers

Most website compromises do not come through the website's own code. They come through an old plugin, a reused password, an unpatched runtime or a third-party script. A useful assessment therefore looks at the whole stack around the site.

Two of these areas cause more trouble than the rest. Access control is covered in our guide on admin access and 2FA, and recovery in website backup and recovery. Plugins and packages have their own risks, explained in plugin and supply chain security.

The Runtime Is Part of the Scope: The PHP2Shell Example

PHP2Shell is a good illustration of why the runtime belongs in scope. It is the name for two critical flaws in the PHP engine, fixed on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The flaw is in PHP itself, not in WordPress, Drupal or Joomla, so a CMS that is fully up to date can still sit on a vulnerable runtime.

An assessment should therefore record the PHP branch, whether it is still supported, and how fixes reach the server. One caution: some Linux distributions backport fixes without changing the version number, so a version banner alone does not prove a server is unpatched. Ask the host or check the distribution's package notes. Our guide to checking your PHP version walks through the steps.

How the Assessment Maps to NIST CSF 2.0, OWASP and CIS Controls

Mapping each finding to a framework makes the report checkable and comparable year over year. You do not need to adopt a framework formally. The table lists the versions current as of October 2026.

The OWASP Top 10 is an awareness list, not a test standard. If you want something closer to a test standard, ASVS is the better reference. OWASP's own example is that an early-stage startup collecting limited sensitive data may focus on Level 1, while "a bank may have difficulty justifying anything less than Level 3." Most small business and local government sites sit near Level 1, with selected Level 2 items for login, session and data handling.

Scan vs Penetration Test vs Assessment vs Audit

These words get used loosely. Here is how the standards bodies use them.

A scan is cheap and fast and finds known problems. It cannot tell you whether a former contractor still has an admin account or whether your backups restore. A penetration test goes deeper on the parts it targets but is narrower. An assessment ties these together. If you take card payments and your acquirer requires ASV scans, an assessment does not replace them.

Public bodies have a free option for the scanning part. CISA's Cyber Hygiene services, including web application scanning that covers the OWASP Top Ten, are available at no cost to state, local, tribal and territorial governments and critical infrastructure organizations. See our government website security page for more.

Rules of Engagement and Permission

Before any active testing, get a written agreement that covers:

• Exactly which domains, subdomains and systems are in scope, and which are not.
• Which methods are allowed: passive review only, authenticated checks, or active testing.
• Permission from the system owner and, where the test touches its servers, from your host or platform. Check your host's terms for its testing rules.
• Test windows, a named contact on each side, and what to do if the test causes an outage or finds evidence of a past compromise.
• How findings and any credentials or data seen during testing will be stored and destroyed.

What You Should Receive

1. Scope and method statement. What was checked, how, and on which dates. Anything that could not be checked should be listed.
2. Executive summary. One page for leadership: overall picture, top risks, the decisions needed.
3. Findings. Each with a description, evidence, affected system, severity, priority, a recommended fix and a framework reference.
4. Fix list. Ordered for action and written so your developer, agency or host can work from it.
5. Vendor questions. Items only a vendor can answer, ready to send. Our guide to reviewing a host, agency or platform has a questionnaire.
6. Readout. A conversation to walk through the results and agree next steps.

Be cautious about any report that gives a single score or a pass mark without evidence. Severity should come from what was found and how it could be used against your site, not from a scanner's default label alone.

How to Prepare for an Assessment

1. List every domain and subdomain you own, including old campaign sites and staging copies.
2. Record who hosts each one, who manages DNS and the registrar, and who builds and maintains the site.
3. Export the list of admin and editor accounts from the CMS, the host control panel and the registrar.
4. Note how backups work and when someone last restored one.
5. List the third-party tools that load on the site: analytics, tag managers, chat, forms, payments.
6. Gather any contracts, service descriptions or security statements from your host and agency.
7. Create time-limited accounts for the assessor rather than sharing your own credentials, and plan to remove them afterwards.

If you cannot complete a step, write that down. A gap in what you know is a finding in its own right.

After the Assessment

Work the fix list in priority order and keep a record of what was done and when. Re-check the highest-priority items once they are fixed. Plan the next assessment around change rather than the calendar: a new host, a rebuild, a new payment flow or a major flaw such as PHP2Shell are all reasons to look again. If the findings show the site is not worth patching, see our overview of website security consulting for the rebuild and incident planning services that usually follow.

Conclusion

A website security assessment is worth paying for when it looks past the website to the hosting, runtime, accounts, backups and vendors around it, maps each finding to a current framework and hands you a fix list someone can act on. Ask for written scope and permission, expect evidence for each finding, and pair the assessment with an incident response plan or retainer so you are ready if something has already gone wrong. If you need help, our website security consulting team can scope one with you.

Frequently Asked Questions