Restaurant website security is a shared job, but each task needs one person or company clearly responsible for getting it done. The owner usually controls who has access and approves changes. An agency may maintain the site. A hosting or website provider may manage parts of the underlying service. The actual split depends on the agreement, so put names, contacts, and response expectations in writing.
Start with the accounts and services that keep guests connected to your restaurant: the domain, website, ordering links, and any reservation tools. Then ask who updates them, who notices a problem, and who can restore service. Paying someone to build a site does not necessarily mean they are monitoring it after launch.
List the accounts, updates, and contacts
Make an inventory before assigning work. Include the domain registrar, website administrator account, hosting account, business email used for account recovery, and any connected ordering or reservation services. For each one, record the provider, the account owner, the people with access, and where recovery instructions are stored. Do not put passwords in a shared spreadsheet or email thread.
The restaurant owner should be able to identify the account holder and retrieve access if an employee or agency leaves. Check that recovery email addresses and phone numbers belong to people the restaurant can reach. A domain can be especially disruptive to lose: see the guide to restaurant website domain ownership for questions to ask.
Next, list what changes over time. A site may rely on a content system, themes, plug-ins, connected forms, and provider-managed infrastructure. Ask the agency or provider which components exist in your setup and who updates each one. Also ask who removes unused accounts and checks that former staff no longer have access.
Finally, collect incident contacts. You need a way to reach the agency and provider, including outside normal business hours if that matters to your operation. Record who at the restaurant can approve a temporary site shutdown, a password reset, or a change to the ordering link. A contact list is only useful if a manager can find it when the website or business email is unavailable.
Assign each security task in writing
The following matrix is a starting point, not a description of every contract. It assumes a restaurant owns its accounts, an agency maintains the site, and a separate provider hosts it. Replace the roles with actual names and confirm the scope with each party. If one company provides both the website and hosting, it may take several of these tasks.
| Task | Lead in this example | What to confirm | Restaurant check |
|---|---|---|---|
| Account access | Owner | Who can add or remove administrators and recover access? | Review access when staff or vendors leave. |
| Website updates | Agency | Which site components are covered, and how are urgent updates handled? | Request a record of completed work and unresolved items. |
| Hosting maintenance | Hosting provider | Which parts of the hosting environment does the provider maintain? | Keep the support contact and account details accessible. |
| Backups and restoration | Assigned provider or agency | What is backed up, how often, and who can restore it? | Ask for the latest restoration procedure and its limits. |
| Incident coordination | Owner or named manager | Who investigates each component, and who makes decisions? | Keep an escalation list and an alternate contact. |
The lead is accountable for moving the task forward; other parties may still need to help. For example, an agency might restore website files while the owner changes an account password. Write down both actions rather than marking the whole incident as the agency's problem.
Ask for specifics in the service agreement or a written support summary: what is included, what triggers an extra charge, expected response windows, and how to request urgent help. A response window tells you when someone expects to acknowledge a request, not necessarily when the site will be fixed. Ask who has authority to act if the owner is unavailable.
If you use a managed restaurant website service rather than separate hosting and an agency, ask the provider to identify its responsibilities and the tasks that remain yours. The same questions apply when comparing a restaurant website builder: who controls access, updates, backups, and support after the site goes live?
Check monitoring, backups, and recovery
Monitoring and recovery solve different problems. Monitoring may alert someone to an outage or suspicious activity; a backup may provide a way to restore content. Neither is useful if no one receives the alert or knows what to do next.
Ask which events are monitored, who receives alerts, and what happens when an alert arrives outside business hours. Does the provider investigate, or only notify the restaurant? Who checks whether the online ordering link still leads to the intended destination? Avoid assuming that a hosting alert covers every connected service.
For backups, ask what is included: website pages, menu content, images, settings, and any data held by connected services may have different arrangements. Confirm how frequently backups are made, how long they are kept, who can request a restore, and whether restoration carries an additional charge. Ask what happens to changes made after the most recent backup; those changes may need to be entered again.
Request a walkthrough of the restoration procedure or evidence of a restoration check. Agree on where a safe check would occur and who approves it. A restored page in a separate environment can help verify content, but it does not prove that every live connection will work. If a provider cannot offer a separate environment, discuss another safe way to verify the procedure without changing the live site.
Also plan a temporary operating alternative. A manager might update a verified business listing or use an existing phone-order process if the website is unavailable. Decide who can make that change and how staff will learn about it. Do not assume a backup alone will restore access to a separate online ordering account.
Walk through a hypothetical incident
Consider this hypothetical setup: a restaurant owns its domain, an agency maintains the website, and a hosting company provides the server. A manager notices that the restaurant website displays an unfamiliar page before dinner service. The cause is unknown. The goal of this tabletop exercise is to practice decisions and contacts, not to diagnose a real attack.
- Record and escalate. The manager notes the time and what appears on the page, then uses the offline contact list to reach the owner and agency. In the exercise, participants describe these calls; they do not send real messages.
- Assign investigation. The agency is the lead for checking the site content and administrative access. The hosting provider is asked to check the hosting environment. The owner coordinates and records who accepted each task.
- Protect accounts and decide on service. The owner confirms who can reset account credentials and approves any temporary changes. The group discusses whether to take the site offline or direct guests to an established alternative. No live setting is changed during the exercise.
- Consider restoration. The agency and hosting provider identify the available backup, its date, and the steps needed to restore it. The manager lists recent menu or hours changes that might need to be re-entered. No restoration is performed in the tabletop exercise.
- Check connected services. The team identifies who would verify the ordering and reservation links after recovery and how staff would handle questions in the meantime. The exercise does not place an order, charge a card, contact a guest, or dispatch a courier.
After the walkthrough, update the matrix wherever a step lacked an owner, a contact was unavailable, or approval was unclear. A tabletop exercise checks the plan, not the technical recovery itself. If you later run a live service pilot or a technical restoration check, agree on its scope and safeguards separately with the responsible providers.
Use the matrix to review your current setup with your agency and hosting provider. Then ask Fleksa about its restaurant website, the security responsibilities for your proposed setup, and current US availability.
Frequently asked questions
Does my website agency handle all security?
Not necessarily. An agency may maintain site content and software while another provider handles hosting. Ask each party for its written scope, including updates, monitoring, backups, and incident response.
Who should own the domain account?
The restaurant should know who holds the domain account and have a reliable way to recover access. Confirm ownership, recovery contacts, renewal arrangements, and what happens if an agency relationship ends.
How often should I review the responsibility matrix?
Review it when a provider, account holder, or key employee changes, and schedule a regular check with your team. Confirm that contacts still work and that each provider's responsibilities remain current.
