What to Ask for in a Website Security and Operational Review
“Can someone review our website?” is a reasonable request, but it leaves out the decision that matters: what should be examined, and what evidence will tell you whether to make a change? A broken contact form, an outdated privacy notice, an account-access problem, and a vulnerable login flow call for different checks. Before buying a scan or commissioning an audit, write down what the site does and what you need the review to answer.
Start with the site and the boundaries
List the domains and subdomains you own, the pages people rely on, and any functions that collect information or require an account. Include downloadable documents, contact forms, chat widgets, booking tools, and third-party services that appear in a visitor’s path. Say whether the reviewer may access only public pages or also authenticated areas. Name the person who can approve tests and supply test accounts. An unlisted portal or externally hosted form should not quietly become part of a test.
For an informational site, an operational review can cover content, navigation, links, notices, forms, communication channels, and the processes used to maintain them. Reliant System’s website compliance audit describes an agreed scope that identifies authorized domains, functions, user journeys, and the requirements selected for review. Ask the reviewer which pages will be examined directly, which will be sampled, and what is out of scope. “All pages” sounds reassuring until you discover the report only checked the home page.
For example: “Review our public main site and the contact journey; exclude the customer portal and payment processor. Sample the product pages and every sitewide notice. Tell us what was not accessible and why.” That is a more useful brief than “make sure our website is secure.”
Separate what visitors see from what needs security testing
A public-page review can identify stale information, broken links, confusing redirects, missing context around a form, or a feedback channel that does not reach its owner. It cannot, by itself, establish whether account permissions, session handling, or input validation are safe. The OWASP Web Security Testing Guide organizes deeper application testing across configuration, identity, authentication, authorization, sessions, input validation, error handling, and business logic. That is a menu of possible test areas, not a claim that every website review includes them.
If the site has a login, uploads, member data, or transactions, ask whether those functions need a separate, explicitly authorized security assessment. Define test accounts, allowed methods, timing, contacts, and any systems that must not be touched. If you only need a public-facing operational review, say so. If you need a penetration test, do not assume it comes with a content and governance audit; the objectives and deliverables are different. Reliant’s comparison of penetration testing and vulnerability assessment helps frame that separate conversation.
Ask who maintains the site between reviews
A finding about an old notice is only useful if somebody can update it. Ask who owns content approvals, plugin and platform updates, the website’s hosting account, and messages from public forms. Who receives an accessibility or security report? Who decides whether a change is ready to publish? What happens when the usual owner leaves? The review should identify the process or missing handoff, not just attach a screenshot of one page.
For WordPress sites, make the maintenance question concrete: who reviews core, theme, and plugin updates, which sources are trusted, who has administrator access, and whether important actions can be traced? The WordPress hardening guide discusses updates, access, backups, logging, and monitoring as parts of risk reduction. Ask what the reviewer can actually verify and what must be confirmed by the host or site administrator. A green scan result is not evidence that ownership and access are healthy.
Recovery deserves one bounded question: what is included in the backup, who can retrieve it, and when was restoration last exercised? WordPress documentation says a typical site needs both database and files for a full backup. A full restore exercise is a separate scope decision, not something to infer from a website content review. If recovery is the main concern, Reliant’s application restore-test guide addresses that question in detail.
Agree how forms and notices will be checked
A form can appear to work while messages disappear into an unmonitored inbox. Decide whether the reviewer may submit a test message, which form and email address to use, who will confirm receipt, and when the test record will be removed. Do not send real customer information just to test a workflow. Reliant’s service description says form and communication checks, when included, are coordinated with designated staff using safe test data and agreed handling procedures.
For privacy or accessibility concerns, identify the pages and reference criteria in advance. An automated check may help find a candidate issue, but it cannot decide every policy or legal question. Ask for observed conditions and affected URLs, then route questions about applicable obligations to management or qualified counsel. Reliant explicitly describes its website audit as an operational and technical review, not legal advice or a guarantee of compliance.
Require a report someone can act on
Before work starts, agree on the report format. For each finding, request the affected URL or function, what the reviewer observed, how it was checked, the likely consequence in your context, a recommended next action, and an owner to confirm or implement it. Separate confirmed observations from assumptions and matters requiring a specialist. A short priority order is more helpful than a long undifferentiated list; record which fixes can be checked again after a change.
Reliant’s published audit deliverables include documented scope and criteria, an inventory or sample of reviewed pages and functions, findings with affected examples where available, prioritized recommendations, and items for management or counsel to confirm. Ask what those artifacts will look like for your site, when you will review the results together, and who will own the follow-up. A review is useful when you can point to both a page-level finding and the next person responsible for it.
A brief you can send: “Please review these authorized domains and visitor journeys: [list]. Include these forms and notices: [list]. Public pages only unless we separately approve authenticated testing. Coordinate test submissions with [contact] using safe data. Report pages sampled, evidence for each finding, exclusions, prioritized actions, and questions that need our management or counsel. Tell us which checks require a separate security or recovery engagement.”