How to Review a Web Host, Agency or Platform for Security

To review a web host, agency or platform for security, ask for its independent reports (usually a SOC 2 report or an ISO/IEC 27001 certificate), send a short questionnaire about the things that actually decide your risk, and get the answers in writing and into the contract. The questions that matter most for a website are who patches the server software and how fast, who restarts it, how backups work, who has access to your site, and how quickly the vendor will tell you about an incident.

You do not need a 300-question spreadsheet to do this well. Large standard questionnaires exist and have their place, but most small organizations and local governments get more from fifteen sharp questions and a vendor who answers them clearly. Below is a copyable questionnaire you can send today, plus a guide to the reports, standard questionnaires and public-sector programs (GovRAMP, TX-RAMP) you will run into, as of October 2026.

Why Vendor Review Matters More Than Your Own Settings

For most websites, the host, agency and platform control more of the security than the site owner does. The host decides when the PHP runtime gets patched. The agency often holds admin passwords. The platform decides which features exist at all. Our guide to the shared responsibility model explains how that split works.

NIST's Cybersecurity Framework 2.0, released in February 2024, made this explicit. Its new Govern function includes a category for cybersecurity supply chain risk management (GV.SC). In plain terms, choosing and checking vendors is now treated as part of security, not a side task for procurement.

PHP2Shell shows why. 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. On managed hosting, the site owner usually cannot apply that fix. Whether the site is exposed depends on how fast the host updates PHP and restarts it. Our guide on what to ask your host about PHP2Shell covers that specific case.

SOC 2 and ISO/IEC 27001: What They Tell You

These are the two reports vendors most often offer.

Two cautions. First, the AICPA has itself been warning about rushed SOC 2 work: its SOC resources page carries headlines such as "Promises of 'fast and easy' threaten SOC credibility" (February 2026) and "AICPA guides peer reviewers to address SOC 2 risks" (May 2026), and says SOC services "should be thoroughly evaluated." Read the report, not just the badge. Second, a small agency or local host may have neither report. That is not automatically disqualifying. It means the questionnaire and contract do more of the work.

Standard Security Questionnaires

Several industry questionnaires exist so that vendors can answer once and share the result with many customers.

If a vendor has already completed one of these, ask for it. It saves both sides time. If it has not, do not ask a five-person agency to fill in a SIG. Use the short questionnaire below instead.

Public Sector Programs: GovRAMP and TX-RAMP

State and local governments have their own cloud verification programs.

• GovRAMP (formerly StateRAMP). The old stateramp.org address now redirects to govramp.org. GovRAMP describes itself as "a nonprofit community providing a clear, risk-based pathway for governments and providers to verify, adopt, and maintain secure cloud solutions," built on NIST controls. Its news page lists Georgia adopting GovRAMP as a statewide framework for cloud service security on 9 September 2026. Check whether your state or agency requires or recognizes it.
• TX-RAMP. The Texas Department of Information Resources says TX-RAMP "provides a standardized approach for security assessment, certification, and continuous monitoring of cloud computing services that process the data of Texas state agencies." Check DIR's page for the levels and who must comply.

A small website vendor may not be listed in either program. Ask your procurement office whether a listing is required for your contract or whether a questionnaire is acceptable. Our page on government website security covers more public-sector specifics.

Questions From CISA's Secure by Demand Guide

CISA's Secure by Demand guide (the PDF is dated August 2024) is written for software buyers. It splits the job into three stages: questions before procurement, security requirements in contract language during procurement, and continual assessment afterwards. Its questions include:

• "How does the manufacturer make it simple for customers to install security patches?" and does it support automatic updates?
• Does it support standards-based single sign-on (SSO) "at no additional cost," and does it enable multi-factor authentication or passkeys by default?
• Has it eliminated default passwords?
• Does it publish a vulnerability disclosure policy, which "should be a public webpage," and file timely CVE records?
• Can it provide a software bill of materials (SBOM) listing third-party components?
• Has it signed CISA's Secure by Design pledge? The pledge is voluntary, launched in May 2024 and has seven goals.

These fit platform and software vendors best. For a host or agency, adapt them: the patching, MFA and disclosure questions carry over directly.

A Short Security Questionnaire for a Web Host or Agency

Copy these questions into an email or a procurement form. Ask for written answers. Where an answer is "it depends," ask what it depends on.

1. Scope. Which parts of our site do you manage: server, operating system, web server, PHP or other runtime, database, CMS core, plugins and themes, DNS, email?
2. Runtime patching. When a critical security release of PHP (or our runtime) ships, how soon do you apply it, and how do you tell us it is done?
3. Restarts. After updating PHP, who restarts the PHP workers or web server so the fix takes effect, and how is that confirmed?
4. Version evidence. If you use distribution packages with backported fixes, how can we confirm a specific CVE is fixed when the version number does not change?
5. End of life. Which PHP branches do you support today, and what happens to our site when a branch reaches end of life?
6. CMS and plugin updates. Who updates core, plugins and themes, how often, and do you test on a staging copy first?
7. Backups. What is backed up (files and database), how often, how long it is kept, where it is stored, and is a copy kept separately from the live server?
8. Restores. When did you last test a restore, and how long would a full restore of our site take?
9. Access. Who on your staff can access our site, hosting and DNS? Is two-factor authentication required for every one of those accounts?
10. Offboarding. How do you remove access when one of your staff leaves, and will you give us a current list of accounts on request?
11. Subcontractors. Do any subcontractors or offshore teams touch our site or data? Who are they?
12. Monitoring. What do you monitor (uptime, file changes, logins, malware), and who receives the alerts?
13. Incident notice. If you detect or suspect a security incident affecting our site or data, how soon will you tell us, how, and who will contact us?
14. Incident support. What will you do in an incident: preserve logs, take the site offline, restore, clean up? Which of those cost extra?
15. Logs. Which logs do you keep (web server, access, admin activity), for how long, and can we get copies during an incident?
16. Evidence. Do you have a SOC 2 report, ISO/IEC 27001 certificate, completed CAIQ or other assessment? Does it cover the service we are buying?
17. Exit. If we leave, how do we get a full copy of our site, database and DNS records, and how long do you keep our data afterwards?

Our guides on admin access and 2FA and backup and recovery explain what good answers to questions 7 to 10 look like.

How to Read the Answers

• Specific beats reassuring. "We apply critical PHP security releases within a set window and email you when done" is an answer. "Security is our top priority" is not.
• Silence is an answer. If a question is skipped, ask again once, then treat it as a gap.
• Check consistency. If the questionnaire says every account has 2FA but the host control panel lets you log in without it, believe the panel.
• Look for ownership gaps. If the host says the agency updates plugins and the agency says the host does, nobody does.
• Write it down. Move the answers that matter (patch timing, backups, incident notice, exit) into the contract or a signed service description.

After You Sign: Keep Reviewing

The Secure by Demand guide's third stage is ongoing assessment, and it applies here. Ask the key questions again each year or at renewal, after a vendor changes ownership, and after a major flaw. In the week after PHP2Shell, a two-line email asking "Have you updated and restarted PHP on our server, and to which version?" is a vendor review. If you need a broader view of your own side, start with a website security assessment, and agree in advance who helps in an incident through an incident response retainer.

Conclusion

A good vendor review is short, specific and written down: ask for the vendor's independent reports and check what they cover, send a focused questionnaire on patching, restarts, backups, access and incident notice, and put the answers that matter into the contract. Standard questionnaires and public-sector programs help when they fit, but they do not replace reading the answers. For a broader picture of consulting work, see what website security consulting covers, or ask our website security consulting team to run the review with you.

Frequently Asked Questions