Hilvy: your service contact
Manage the setup, investigate problems, coordinate suppliers and keep your team informed within the agreed support terms.
Your website. Our responsibility.
Managed hosting with Hilvy as your point of contact. We look after the agreed technical service, coordinate the platforms behind it and keep your team informed when something needs attention.
Working proposal · 8 September 2026
For procurement and security review. This describes the service we propose to provide, not controls already verified for your site. The signed agreement will define the scope, cover and service levels.
One service contact.
Clear responsibilities.
You contact Hilvy about the managed service. Our role includes handling the technical investigation and supplier escalation, not sending your team between help desks.
Your organisation
Retain domain control, approve content and tell us who can publish and what data the site needs to handle.
Platform providers
Run the underlying hosting and CMS services under their own agreed terms.
If something goes wrong,
we stay with it.
Proposed incident process. Support hours, response targets and update frequency will be recorded in your service agreement.
Acknowledge and investigate
Assess an alert or report, establish what is affected and give your team a clear update.
Act and coordinate
Fix what is within our control. Escalate platform faults and assess safe recovery options.
Check and follow up
Verify recovery, explain what happened and record any changes needed to reduce repeat incidents.
Our agreement is with you.
Hilvy’s service commitments are separate from the platforms’ terms. We do not assume an enterprise provider SLA is included. A supplier outage does not remove our role in communication and escalation, but we cannot promise a supplier’s repair time.
The agreement will distinguish website availability, editing and publishing, and Hilvy’s response. It will also define how downtime is measured, exclusions and any service credits. Always-on is the aim, not a promise that no outage can ever happen.
Built to keep reading
separate from editing.
Sanity for content editing. Astro for building pages. Vercel Pro or an appropriate Cloudflare hosting plan for delivery on your custom domain.
Edit in Sanity
Your approved editors manage content.
Build with Astro
Publishing triggers a checked website build.
Serve the published site
Visitors see the last successful deployment.
With this approach, a CMS interruption can delay editing or publishing without taking the prebuilt pages offline. Images loaded from the CMS, forms and other live features remain separate dependencies to review. Hosting or DNS outages can still affect the public site.
Public pages and personal data
need different decisions.
We start by checking what your forms collect and where submissions go. Where suitable, enquiries can go straight to a system your organisation already approves instead of being stored in the website CMS.
A form does not automatically require UK-only hosting. Your organisation may have its own location requirements. We review processing, storage, logs, backups and support access before choosing the final setup. A UK server region alone is not proof that all processing stays in the UK.
ICO guidance on international transfersThe website and its data
What kind of website does this cover?
This overview covers managed hosting for public-facing websites with CMS access for approved editors. The scope is agreed for each organisation. Payments, customer accounts, file uploads and sensitive personal data are not included by default; they need a separate review before being added.
Does a public website handle personal data?
It can. Editor accounts, visitor logs, analytics and enquiry forms may contain personal data even when the pages are public. Before launch, we would map what is collected, why, where it goes and how long it is kept. Where appropriate, forms can connect to an approved existing system, with the data flow and responsibilities documented.
Where would the site and content be stored?
The proposed stack is Sanity for content, Astro for website code and a private GitHub repository for version control. Hosting candidates are Vercel Pro or an appropriate Cloudflare service and plan. Final choices depend on access, data-location and service requirements. We would document storage, backups, logs and support-access locations before approval. UK-only processing is not assumed.
Who is responsible for data protection?
The agreement would identify your organisation’s and Hilvy’s roles for each processing activity. Where Hilvy processes personal data on your instructions, appropriate data processing terms and authorised subprocessor arrangements would be needed. Optional AI features would require separate approval; they are not assumed in this proposal.
Access and everyday security
Who could access the website systems?
The proposed baseline is named accounts, multi-factor authentication and access limited to each person’s role. Content editors would not need infrastructure administration rights. Joiner, role-change and leaver procedures, access reviews and your organisation’s single sign-on requirements would be agreed and checked against the selected plans.
Could our security team have access?
Yes, the proposed arrangement can include scoped reviewer access where the chosen services support it. Permissions would be agreed per system, avoiding access to other clients. Evidence exports are an alternative where a read-only role is unavailable. Broad access to Hilvy’s entire hosting account would not be appropriate.
How would you protect the site and make changes safely?
The proposed baseline includes HTTPS, protected credentials outside source code, reviewed releases, dependency updates and separation of preview and production. Encryption at rest, audit logging, traffic protection and customer isolation would be verified for the actual services and plans. Testing would avoid live personal data unless specifically approved.
Do platform certifications also certify Hilvy?
No. Provider certifications cover their stated services and scope, not Hilvy’s entire operation or this website. Any request for Hilvy certifications, independent testing or insurance evidence needs a separate, current response. This overview does not assert that those assessments have been completed.
Support, backups and continuity
What support and uptime would be included?
Hilvy would provide the client-facing service agreement. It would distinguish public website availability, editing and publishing, and our incident response. Support hours, measurement, exclusions and any service credits need to be explicit. Automated monitoring is separate from staffed response. Provider enterprise SLAs are not assumed, and this proposal does not promise a particular uptime percentage or round-the-clock staffing.
What would happen during a security incident?
The proposed process is to assess and contain the issue, notify your nominated contacts, coordinate recovery and record the cause and follow-up actions. Security reporting channels, notification deadlines and responsibilities would be agreed before launch. A technical alert alone is not a complete incident-response service.
What would be backed up?
Daily backups are proposed, with coverage for CMS content, uploaded media and the configuration needed to restore the site, alongside versioned code. Retention, protected separate storage, failure alerts and restore testing still need to be specified. Git history and deployment rollback do not, on their own, restore deleted CMS content.
How quickly could the site be recovered?
Recovery targets would be agreed after the stack and backup process are defined and tested. We would distinguish recovery time from the amount of recent work that could be lost. A successful daily backup can leave nearly a day of changes to recover manually; it does not establish how quickly a restoration can finish.
What if Hilvy or the hosting provider became unavailable?
The continuity plan would cover both cases separately. Proposed safeguards include an authorised backup operator, documented recovery steps and a transfer route for code, content and configuration. Your organisation should retain control of its domain. A provider outage may still interrupt service; automatic failover to another platform is not assumed.
Ownership, accessibility and leaving
Can we move to another supplier?
The contract should define ownership and licences, usable code and content exports, migration assistance, notice periods and any exit charges. Hilvy can manage the day-to-day platform account while agreeing a practical handover route. Transfer limits, deletion deadlines and backup expiry would be documented before signing.
How would accessibility be handled?
We would agree your organisation’s accessibility requirements, testing scope and responsibility for ongoing content changes. The review would identify applicable standards, such as WCAG 2.2 AA, and any requirement for an accessibility statement. Automated checks alone would not establish conformance; manual testing and documented remediation are also needed.
What needs to be agreed before the service starts?
The final scope, providers and locations, access model, support and recovery targets, backup policy, data processing terms, evidence requests and exit arrangements. This page explains the proposed approach. It is not a signed SLA, a security certification or confirmation that these controls are already operating.
A straightforward review.
Send your procurement checklist and any data-location or access requirements. We’ll set out the proposed service, supporting evidence and remaining decisions in one place.