Journal
Choosing a website platform when your IT team has opinions
Marketing wants something easy to edit. IT wants something secure and supported. Both can usually be satisfied.
In many Cambridge organisations, choosing a website platform is a negotiation. Marketing and communications want a site they can edit easily and change quickly. IT and information security want something supported, patched and compatible with their policies. In science and research organisations there may also be data protection, export control or customer security questionnaires to think about.
These goals are not really in conflict. Most disagreements come from not discussing requirements early enough. Here is how we approach it.
Write down the requirements first
Before comparing platforms, agree what the site actually needs to do. A short list, signed off by both teams, avoids months of back and forth. Typical questions:
- Who will edit content, and how often?
- Does the site handle any personal data beyond contact forms?
- Are there gated areas, logins or customer portals?
- Must it integrate with internal systems, such as single sign-on, CRM or HR?
- Are there hosting location requirements, for example UK or EU only?
- What uptime and recovery times are expected?
- Will customers or partners send security questionnaires that cover the website?
The main options
Static sites
The site is built into plain HTML files and served from a content delivery network. There is no database or server-side code running on each request, which removes a whole category of security risk. Static sites are fast, cheap to host and very low maintenance. Content can be edited through a headless CMS or files in a repository.
They suit marketing sites, company sites and most research group sites very well. They are less suited to sites with lots of user-specific content.
Traditional CMS (WordPress, Drupal and others)
A server runs the CMS and database, generating pages on request. Familiar for editors, flexible and well supported, but with more to maintain: core updates, plugins, server patches. Managed hosting reduces this burden considerably.
Drupal is common in universities; WordPress is common everywhere. Either can be run securely with the right hosting and maintenance.
Headless CMS with a static or hybrid front end
Content is managed in a hosted CMS, and the website front end is built separately. This combines easy editing with the security and speed of static delivery. It suits organisations with a lot of structured content, such as publications, people and events, or those that publish the same content to several places.
Website builders
Hosted builders can work for very small sites, but often struggle with IT requirements around access control, data location, custom integrations and exit strategy.
Questions IT will ask, and good answers
| Question | What a good answer covers |
|---|---|
| Who has access? | Named accounts, role-based permissions, multi-factor authentication, single sign-on where possible |
| How is it patched? | Who updates what, how often, and how changes are tested before going live |
| Where is data stored? | Hosting region, where form submissions go, retention periods |
| What third-party scripts run? | A short list, with a reason for each, and a consent approach for anything non-essential |
| How is it backed up? | Frequency, location and a tested restore process |
| What if the agency disappears? | Code in your own repository, documentation, domain and accounts in your name |
Forms and personal data
Even a simple contact form handles personal data, so IT and data protection colleagues will want to know where submissions go, who can read them and how long they are kept. Sending form data straight to a known system, such as a shared inbox, a CRM or a ticketing tool, is usually easier to approve than storing it in the website’s own database. Keep the questions to what you actually need. A careers form asking for date of birth, or a partner enquiry form asking for a phone number nobody will use, creates data you then have to protect.
If the site uses analytics, decide early whether you will use a cookie-free tool or a consent banner, and make sure the privacy notice describes what really happens.
Keep ownership in-house
Whatever platform you choose, make sure your organisation owns the domain, the hosting account (or at least has admin access), the code repository and the CMS. Agencies change and staff leave; access should not leave with them.
Limit third-party scripts
Analytics, chat widgets, video embeds, social feeds and marketing tags each add weight, privacy considerations and potential security risk. Ask for a reason for each one. Removing scripts that nobody uses is often the quickest win for speed, privacy and security at once.
Comparing the options side by side
| Static | Traditional CMS | Headless + static | |
|---|---|---|---|
| Editing | Basic unless paired with a CMS | Familiar, flexible | Structured, friendly |
| Security surface | Very small | Larger: server, plugins, database | Small front end; CMS is hosted |
| Maintenance | Minimal | Regular updates needed | Low |
| Speed | Very fast | Depends on hosting and caching | Very fast |
| Best for | Small company and project sites | Sites with many editors and plugins | Content-rich sites, several audiences |
A worked example
A hypothetical medtech company on a business park north of the city has an ageing WordPress site. Marketing want to publish news and case studies quickly. IT have been asked by a hospital customer to complete a supplier security questionnaire, which includes questions about the website. The company also wants a gated area for distributor documents.
A sensible answer might be a static front end with a hosted headless CMS for news and case studies, single sign-on for CMS editors, and the distributor documents moved to the company’s existing document-sharing platform with a link from the site, rather than building a login system into the website. The questionnaire answers become short and easy to defend, marketing get an editor they like, and nobody has to patch plugins on a Friday evening.
What a sensible handover looks like
Whatever platform is chosen, IT will be happier at launch if the handover is complete. That means a short document listing every service the site depends on (hosting, CMS, DNS, form handling, analytics, any third-party scripts), who has admin access to each, how deployments work, how backups are taken and restored, and who to call when something breaks. It should also record renewal dates for domains and certificates, which are a surprisingly common cause of sites going offline.
Ask for a test restore from backup before launch, not after the first incident. It takes an hour and tells you whether your recovery plan actually works.
Finally, write the handover down somewhere other than the agency’s systems. A shared folder owned by your organisation, with the document, the access list and the renewal dates, means that whoever is responsible in three years’ time can find everything without having to track down the people who built the site.
Questions to settle before you commission
- Who signs off the platform choice, and who can veto it?
- Are there approved suppliers or hosting regions?
- Does single sign-on need to cover CMS editors?
- Which analytics tool is approved, and does it need consent?
- Who will be the technical owner after launch?
We cover these trade-offs in more detail on our web development and WordPress websites pages, and our guide to website costs covers the running-cost side.
A typical outcome
For many Cambridge companies, the result of this conversation is a static or hybrid site with a hosted headless CMS for editors, form submissions sent to a known system, a short list of approved scripts, and code in the organisation’s own repository. Marketing gets an editor they can use; IT gets a small attack surface and clear ownership.
That is not the only good answer, but it is a common one, and it is a useful starting point for the discussion.