Who keeps your small-business website secure after launch?

Your new website is live. The designer has handed over the links, the contact form works, and the team has moved on to other work. A few months later, a plugin asks for an update, the domain renewal message goes to a former employee, or an inquiry stops reaching the right inbox. Who is supposed to notice and act?

Website security needs a named owner and a repeatable routine after launch. The owner does not have to perform every technical task. They do need to know which accounts and data matter, who maintains each part, how to confirm that protections work, and whom to call when something goes wrong. Write those answers down while everyone can still access the systems.

The wider business risk is real, though a national survey cannot predict what will happen to one website. Statistics Canada reported that 16% of Canadian businesses with at least 10 employees were impacted by a cyber security incident in 2023. Its survey excludes smaller enterprises and public administration, counts incidents the business considered impactful, and covers cyber incidents across the business, not just website attacks. Use it as context for planning, not as a website breach rate or a forecast for your firm.

Start with an ownership map

List the systems that keep your site available and trustworthy: the domain registrar, DNS provider, hosting account, content management system or code repository, form or booking service, email destination, analytics, and any payment or client portal integration. A simple site may have only a few of these. A custom application may have many more.

For each system, record the business owner, the person or provider with administrator access, the renewal or billing owner, and the route for urgent support. Keep the inventory in a place the business can reach if the website or normal email is unavailable. Do not put passwords in the inventory; use your approved password manager and recovery process. Review access when staff or suppliers change roles.

Your business should control the domain registration and have a way to recover the registrar account. For a .CA domain, CIRA advises keeping registrar account details safe and asking whether the registrar supports multi-factor authentication for changes. Check where renewal notices go, who can change DNS, and whether a departed contractor is the only person who can make an update. CIRA is the .CA registry, not your registrar or your website host, so the exact controls available depend on the provider.

Protect the accounts that can change the site

Start with the accounts that can redirect the domain, deploy new code, publish pages, change a form destination, or read submissions. Give each person their own login where the service supports it. Limit permissions to the work they actually do and remove access that is no longer needed. A shared administrator password makes departures and incident review harder.

Turn on multi-factor authentication for the registrar, hosting, content management system, email, and other administrative accounts where available. Use unique credentials and a tested account recovery method. The Canadian Centre for Cyber Security’s foundational guidance recommends distinct passwords, multi-factor authentication, and a record of digital assets that includes websites and cloud services. The aim is to make an account takeover less likely and to avoid being locked out of your own site.

Ask the provider what happens when the person with primary access leaves. Can the business remove that access without losing the site? Who holds backup recovery codes, and how are they stored? A handover is complete only when the business can use the accounts, not when a document says it owns them.

Agree on updates and recovery before you need them

If your website uses a content management system, themes, plugins, or server software, someone must track and apply security updates. An automatically deployed site still depends on maintained libraries, hosting configuration, and account access. The Cyber Centre’s website guidance calls for patching underlying systems, content management systems, web applications, and plugins. Ask your developer or host what each party updates, how urgent fixes are handled, and how changes are checked afterward.

Decide what must be recoverable. That may include page content, images, application code, configuration, form submissions, and a database. A host may back up some items but not everything you need. Ask what is included, how long copies are kept, where they are stored, and who can restore them. A backup that has never been restored is an untested assumption. The Cyber Centre’s backup guidance recommends protecting copies from the original system and testing recovery.

For a small service site, try a practical recovery exercise: identify a page or test record that can safely be restored without disrupting live customer data, then have the responsible person show the steps. Record what was recovered and what was missing. If there is a client portal or sensitive database, use a planned test environment and a qualified operator rather than experimenting on the live system.

Follow the inquiry data, not only the homepage

A healthy-looking homepage does not prove the contact path is healthy. Trace a test inquiry from submission to confirmation, notification, storage, and deletion. Find out who can read submissions in the website, email, form provider, or customer system. Limit access to the people who need it. If you work with financial or other confidential records, keep those documents out of an ordinary first-contact form and move the conversation to an approved channel when needed. Our guide to an accounting firm’s first-contact form covers that narrower privacy and routing question.

Check that the public site uses HTTPS and that any service handling submitted data uses secure connections as configured. The Cyber Centre’s website guidance recommends HTTPS by default and secure connections between web components. The padlock alone does not prove the application, accounts, or data storage are secure; it protects the connection in transit. A developer should review how forms validate input and how any logged-in areas control access.

Plan for ordinary errors as well as malicious activity. A form can fail because a destination address changed or a provider reached a limit. Assign someone to make a routine test inquiry and confirm that the right person received it. If the business serves customers in English and French, test the confirmation and reply path in both languages that the site offers.

Decide how you will notice and respond

Choose a small set of signals that someone will actually review: domain renewal alerts, hosting or uptime notices, failed deployment alerts, unexpected content changes, suspicious sign-ins, and missing inquiry messages. Give every alert a recipient and a backup recipient. Avoid collecting more personal data or buying monitoring tools without a clear reason to use them.

Write an incident note that fits on one page. It should say who can contact the registrar, host, developer, and email or form provider; who can decide to pause a feature; where a known-good copy is; and how the team will record what happened. Keep provider contact details available away from the affected site. The Cyber Centre recommends an incident response plan with named responsibilities and contact information that remains available during an outage.

If the site is defaced, an administrator account looks compromised, or inquiries may have been exposed, involve the appropriate technical and privacy specialists promptly. Preserve evidence and use their advice on containment, recovery, and any notice obligations. The right response depends on the system and information involved; an article cannot determine it for your business.

Make the handoff a working agreement

Ask a prospective website partner for an ownership and maintenance handoff in plain language. It should identify the accounts the business controls, what the partner manages, how updates and backups work, how to request a change, and what support is available after launch. If security work or incident response is outside the project, name the person or specialist who will handle it. Avoid a vague promise that the website is “secure”; ask for specific responsibilities and checks.

For a bookkeeping practice, that might mean the practice owns its domain and business email, a developer maintains the site software, a form provider stores initial inquiries, and a practice manager tests the inquiry route and approves who can read it. The exact split depends on the tools and contract. What matters is that each handoff has an owner and can be tested.

Security is ongoing work, but the first useful step is small: make the inventory, confirm control of the key accounts, and assign an update, backup, and response owner. If you are planning a new service website and want those responsibilities defined during the build, discuss the website scope with Red Comet.

Sources

• Statistics Canada, Impact of cybercrime on Canadian businesses, 2023.
• Canadian Centre for Cyber Security, Foundational cyber security actions for small organizations.
• Canadian Centre for Cyber Security, Security considerations when developing and managing your website.
• Canadian Centre for Cyber Security, Tips for backing up your information.
• CIRA, .CA domain support and security questions.