CMS Specification - Draft
- Ali González
- Mathias Bolt Lesniak
Note on imperatives: The keywords must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in RFC 2119.
1 Version History
v1 — February 2025
2 Description
2.1 Premise
The CMS Building Block is a comprehensive model for the standardization of government websites, through the use of content management systems (CMS). By extension, it also covers the websites of all public institutions, including central agencies, local and regional administration, embassies, other public authorities, and educational institutions.
The GovStack CMS building block prescribes CMSs as the basis for portals offering citizens access to government information and services.
The CMSs should be able to utilize and integrate with other GovStack Building Blocks. The model therefore uses three overarching criteria to ensure compatibility with the Building Blocks concept and the requirements of a government use case. CMSs should be:
Built for interoperability and easy integration.
Standards-based, preferably using open source.
Designed for scale, flexibility, and upgradability.
2.2 Coverage
The model is a comprehensive conceptualization of the following organizational and operational fields, including related technical and methodological capacity-building and training programs:
Planning
Governance
Development
Deployment
Hosting
Security
Maintenance
Content editing
2.3 Flexibility
The approach is flexible and can be adapted to the ecosystem of each country, accounting for differences in:
Stakeholder harmonization
Local technical readiness
Availability of technical capacity for all relevant roles
Regulatory framework
Technical culture
Available funding sources
Development cooperation actors
The Role of CMSs in Government and Public Administration
Information and services reflecting the country
Maintaining a modern and efficient web presence is a fundamental necessity for all national governments and central and sub-central public institutions. It is achieved through a well-planned, well-executed, and well-maintained information delivery based on one or more online content management systems.
Government web portals are a window to the country, reflecting its identity, giving access to the most important and up-to-date information, as well as to key public services, for the citizens, companies, investors, and tourists.
Thus, government web portals have two major functions:
Delivery of up-to-date information in a well-structured and accessible manner.
Provide an entry point to electronic public services (e-services)
Standardizing for consistent governance, quality, and efficiency
In order to achieve these goals in an efficient manner, the governmental web portals need to be secure, performant, scalable, attractive, accessible, and user-friendly. It must present a cohesive content structure that allows quick information retrieval and effective navigation.
The user experience needs to be consistent across all institutions and their online properties, following the same informational flow and reflecting a common visual identity. Behind the scenes, the hosting, development, and maintenance processes should be conducted based on common governance to minimize costs, resource consumption, security risks, and dependency on external service providers.
These considerations are not only true for the central government organization. They should also apply to regional and local institutional entities. These websites also provide information and services to citizens, businesses, and other interested stakeholders.
Establishing a digitally sovereign platform
There are significant benefits in establishing a single national model covering the following institutional categories:
Central government, including ministries and top-most institutions (e.g., presidency, parliament, prime minister office, etc.)
National government agencies
Regional and local governments (e.g., provinces, districts, municipalities, and other administrative units)
Embassies and other diplomatic missions of the country
Digital sovereignty is especially important when establishing this platform, so the government can ensure that it maintains ownership of data, retains control over digital assets, and avoids vendor lock-in.
Creating opportunities for the national economy
The life cycle of the websites created through this building block should provide opportunities for job creation and sustainable business opportunities for local companies. All services required for the development, maintenance, hosting, monitoring, upgrading, extending, and integrating the websites could generate new business and create employment opportunities for local talent.
Standardizing the life cycle of government websites
The critical mission of government and public institution websites is to keep citizens and other stakeholders informed and to provide entry points to e-services. This makes it imperative to establish standardized governance models that can ensure the continuity, resilience, accessibility, and coherence of the websites and related supporting processes.
Central standardization goals
The standardization should aim to ensure:
Coherent and consistent presentation of information to the stakeholders. Information should be structured in a predictable manner, where the website’s content taxonomy and availability of services can be identified with ease.
Consistent identity, styling, and user experience design that allows easy navigation in the informational structure and rapid identification of the next steps to achieve end-user goals.
Consistent ways for staff to add and edit content. Editors from all institutions should be able to follow the same formal learning path and use the same approaches to complete the same tasks.
Effective and efficient technical development and evolutive maintenance at minimal cost and with minimal risk will allow central governance of the technical processes. They can be executed by a compact, dependable, and predictable development capacity with predictable training goals that cover updates, upgrades, development of additional features, integration of additional components, etc.
Coherent planning, implementation, and management of the hosting infrastructure, following the same rules for continuous integration (CI), continuous deployment (CD), and monitoring, to ensure proper security, performance and availability.
Minimum general requirements
The standardization concept requires that a government website meets high requirements for:
Security
Scalability
Accessibility
Extendability
Integration with external services
Lifecycle components requiring standardization
The lifecycle components that require standardization are:
Development
Maintenance and extension
Upgrades, updates, and patching
Integration
Deployment and hosting
Performance monitoring
Cybersecurity auditing and security monitoring
Disaster recovery
Technical support
Technical project management
Content editing
Content migration
Training and onboarding for content editors
Recommended standardization enablers
The standardization of the following elements is recommended in order to enable the other standardization steps:
Identity and user experience
Technical training of developers
Training of content editors
Strategic governance of government website implementation and maintenance
Common negative effects of a decentralized approach
Traditionally, the responsibility to implement institutional websites has been delegated to each individual institution or its immediate administrative superior.
Deeply rooted institutional autonomy and lack of centralized standard guidelines and regulations have often led to the perpetuation of an ad-hoc approach where each public institution is responsible for the entire life cycle of its own website, encompassing conceptual development, content structure, technical architecture, implementation (or contracting of development services), maintenance, hosting, upgrades, extensions, integrations, security, performance, accessibility, replacement/disposal and data migration.
Benefits of a centralized standardization approach
A centralized approach to governance is central to a successful strategic standardization of government websites. It will ensure coherent management and decision-making, as well as reduce the cost and management overheads associated with widely distributed management approaches.
Centralized and standardized governance models have already been established for the websites of central governments. In some cases it has also been extended to other categories of public institutions as well.
Relevant examples of government website standardization are those of the United Kingdom, Peru, Germany, and Rwanda (this list may not be exhaustive or complete.)
Management with clearly defined accountability
Centralized and standardized governance requires that the management of the entire life cycle of the websites is assigned to and taken on by a single institution or a group of institutions under a single clearly defined accountability agreement.
Such a governance structure must contain at least the following:
Benchmarking and identification of the optimal CMS technology, following this specification.
Planning the development and the rollout of new websites and the migration of information assets.
Ensure the application of relevant rules and guidelines. For example, graphic identity, accessibility, domain naming, hosting, and monitoring.
Train and support the technical capacity required to define, specify, supervise, and evaluate the technical implementation tasks.
Plan for major evolutive maintenance operations, such as major technological upgrades.
Ensure technical support for all institutions that have a standardized website.
Train and support the content editors of all institutions that have a standardized website.
Identify, competitively procure, and assign the technical capacity that can provide development and maintenance activities when needed.
3 Terminology
Content Management System (CMS)
A software application used to create, manage, and publish digital content, typically for websites. A CMS allows users to create and edit content without needing to have advanced technical knowledge or expertise in web development. Content can include text, images, videos, and other multimedia formats.
There are many different CMSs available, each with its own strengths and weaknesses. Some CMSs are designed for specific use cases, such as e-commerce or blogging, while others are more general-purpose. Popular CMSs include Drupal, Joomla, TYPO3, and WordPress.
Digital Sovereignty
Digital sovereignty refers to a government, organization, business, or individual's ability to maintain independent control over their digital assets, data, and operations.
Accessibility
Accessibility is the design of products, services, [...] or environments so as to be usable by people with disabilities. The concept of accessible design and practice of accessible development ensures both "direct access" (i.e. unassisted) and "indirect access" meaning compatibility with a person's assistive technology (computer screen readers, keyboard-only access). Source: https://en.wikipedia.org/wiki/Accessibility
Backend
The content publication and administration interface of the CMS. Commonly requires a user login for any access.
Frontend
The end-user facing, published content. Usually presented as a web page on a website. The frontend is publicly accessible by default, but may have restricted sections, requiring user login in order to be viewed.
SEO
SEO, short for search engine optimization, is about helping search engines understand the website’s content, helping users find the site, and making a decision about whether they should visit the website site.
4 Key Digital Functionalities
Key Digital Functionalities are the core (required) functions that this Building Block must be able to perform.
The Building Block will be accessible through the web browser, through all suitable devices such as PCs, notebooks, mobile phones, tablets, and public touchscreen displays.
Primary user categories
The functionalities are divided into two primary categories, depending on the role of the user that is interacting with the CMS:
Backend/backoffice functionality is available to website administrators and content editors.
Frontend functionality is available to website visitors (citizens, etc).
Terms used for functionalities
To define functionalities, the following terms will be used:
Content block: A modular section of content within a webpage that is structured as a standalone unit, consisting of text, links, images, videos, or buttons, designed for easy customization, rearrangement, or reuse
Grid of content blocks: A structural element that arranges content blocks within a grid layout. It organizes the content blocks into rows and columns with consistent responsiveness and visual balance when viewed on devices with differing screen sizes.
Media: Any type of content that can be displayed, played, or interacted with on a website. Types of media files include images (JPG, PNG, GIF, SVG, WEBP), PDF files, videos (MP4, embedded YouTube/Vimeo), audio (MP3, WAV, podcasts).
Slider: A component that displays multiple pieces of content, such as images, texts, or videos, as a dynamically changing sequence of image and text slides displayed in the same location, often with a sliding effect transitioning each slide. Users can navigate through the slides manually (by swiping or clicking arrows or dots) or automatically. A slider is also known as a carousel.
Banner: A prominent visual element used for branding, promotions, or important messages. It includes text, images, buttons, or animations meant to capture the user’s attention.
Accordion: A user interface component that organizes content into collapsible sections. Each section expands when clicked or tapped, revealing hidden content, and typically collapses when another section is opened.
Tabs: A user interface component and navigational element that organizes content into multiple sections, allowing users to switch between them without leaving the page. An analogy to tabbed dividers in a filing cabinet, each tab represents a different section of content, and only one section is visible at a time.
News: Information published online, typically covering current events, updates, or announcements, presented in article format. A news article commonly consists of title, subtitle, author’s name, date and time of publication (or update), summary, body content (main article), images, videos, categories, tags, and social sharing options. News articles may feature user comments.
Backend user: An individual who has been granted access to the Backend, commonly responsible for creating, editing, and organizing the website’s content and other administrative tasks. The user’s specific capabilities are defined by and tailored to their assigned role and responsibilities.
Available websites: one or more websites published by a CMS instance.
Backend functionality requirements
This section lists functionalities that are minimum requirements for the CMS backend.
A backend user, unless restricted by access rights, must be able to:
Upload, manage and use files for public content creation.
Create and manage navigational structures and menu items.
Create and manage content pages.
Create and manage content blocks of at least the following types or combinations thereof:
Text
Media
Image slider
Content block slider
Banner
Table
Accordion
Tabs
File download
News
Forms
Create and manage grids of content blocks.
Create and manage SEO-relevant settings for each page and content element.
Create and manage accessibility-relevant settings for each content element.
Create and edit hyperlinks to internal or external web pages.
Create and manage publishing workflows, including content approval.
Create and manage content languages through a visual user interface.
Localize and translate pages and content blocks in all available content languages.
Create new and manage existing websites using a unified visual interface.
Copy/cut and paste individual pages or content blocks.
Copy/cut and paste content structures, such as groups of pages and content blocks.
Reuse existing content across one or multiple websites while keeping a single editable source (no redundancy).
Export and import content structures using an open file format or API.
Create and manage backend users, manage user roles, and set granular permissions.
Restrict backend user access to specific websites, website sections, or individual pages.
Frontend functionality requirements
This section lists functionalities that are minimum requirements for the CMS frontend.
All visitors to the website (frontend users) must be able to:
Navigate the content structure using the menu and links.
Switch between content languages.
List and read current and historical news articles published on the website.
Search the website content using keyword search.
The Frontend functionality should be accessible to all users, including those with disabilities.
General functionality requirements
The following functionality requirements affect both backend and frontend user experience.
Link management system
The CMS should facilitate the creation of both internal and external hyperlinks. The internal linking mechanism must ensure:
Portability and flexibility: Pages can be moved and renamed without breaking links to them. This also includes maintaining link integrity within the CMS instance when it is replicated and deployed across different environments (e.g., development, staging, and production).
Maintenance and consistency: Editors must be able to update site structure or reassign domains without being required to manually adjust every internal hyperlink.
Scalability in Multisite or Multilingual context: Internal hyperlinks must automatically adapt to the current site and language context.
File management layer
The CMS must provide a unified and consistent interface for managing files, regardless of their underlying storage location or system. The file management layer must ensure the following:
Uniformity: A single user interface and a single API, whether files are stored locally, on remote servers, or in cloud-based storage
Portability: Ease of migration and scaling of websites across different environments without changing the file management logic. “Environments” in this context refer to development, testing, staging, and production servers, any of these environments being powered by Linux or Windows operating systems. The same applies to the ability to migrate and scale websites to or between local systems and cloud platforms.
Flexibility and extensibility: Allow integration with multiple local or remote storage systems and file services.
5 Cross-Cutting Requirements
This section describes essential requirements that apply to the software and processes involved in this building block.
Wherever applicable, the term CMS also includes third-party components (i.e., extensions, plugins, modules) necessary to achieve the functionality required by the building block.
Security (REQUIRED)
The framework must ensure a high level of security, including, but not limited to:
Multi-Factor Authentication (MFA)
Industry-standard encryption algorithms
Secure practices by default
Including files stored outside the web root and granular access rights for assets, files, and folders
Triggerable password resets from the backend
Granular access control for the administrators and site editors
The CMS must have at least:
Maintenance by a dedicated team
Security announcements with a subscription option (e.g. through email)
A dedicated security team
Third-party extensions should be curated to minimize the risk of introducing security vulnerabilities.
Multi-tenant capabilities (REQUIRED)
The CMS must allow multiple websites and web domains to run on one instance of code. This will allow upgrades, patches, and functional additions or changes to be propagated on all websites that run on the same instance.
Sharing of content and backend user accounts should also be possible between individual websites.
Multilanguage and content translation (REQUIRED)
The CMS must allow easy setup and management of languages and easy translation of all content using a unified API.
Stability (REQUIRED)
The stability of the functional components in the CMS must be documented through independent quality review or through historical evidence of use within the government sector.
Operational stability with large data sets and high traffic volumes should also be ascertained.
Configurability (REQUIRED)
The CMS must be highly configurable without the use of procedural programming or changes to core files.
The configuration should be deployable as configuration files or code.
Frontend output must be sufficiently configurable to allow compliance with any existing government design style guides.
Predictable upgradability (REQUIRED)
The CMS must be updatable with a predictable and minimal risk of breaking functionality on patch releases.
The CMS must provide documentation on breaking changes and deprecations. Breaking changes should be introduced in a predictable manner in major releases unless the breaking change is introduced to mitigate a security issue that cannot be mitigated through other measures.
The CMS should have a predictable upgrade roadmap to ensure that the website is kept up to date as the technologies evolve, that it remains secure, and that its underlying technology is continuously maintained.
Each version of the CMS should have a defined release lifecycle, including the length of official support (the period of time during which bug fixes and security patches are provided after initial release). This will enable the length of the lifecycle to be matched with the expected lifecycle of the government websites.
Extensibility (REQUIRED)
The functionality of the CMS must be extensible through third-party components (i.e., extensions, plugins, modules) without changing the code of the CMS itself.
It must be possible for the implementation team of this building block to use their self-developed components with the CMS.
Open source license (RECOMMENDED)
The CMS platform and its source code should be available under an open source license approved by the Open Source Initiative (OSI).
A broad community of contributors (RECOMMENDED)
The CMS should have a wide international community of technical developers that maintain expertise and contribute to the development of the platform and additional components.
The community should be governed by a published code of conduct and be conducive to the sharing of knowledge and experience.
Deployability (REQUIRED)
The CMS must support the completion of effective automated deployment to remote servers and cloud solutions without accessing the CMS’s graphical user interface.
The technical interventions on the websites should follow a proper continuous integration and continuous deployment (CI/CD) process to ensure that the production environments remain stable and available continuously and that replicable on-deploy upgrade functionality can be implemented, for example, in development and live environments
Scalability (REQUIRED)
The CMS must adapt seamlessly to growing traffic and increasing amounts of content, including media/photos. It must have an efficient approach to managing large databases of media assets. It should support the generation of optimized assets on rendered web pages to ensure page loading performance.
Search Engine Optimization (SEO) (REQUIRED)
The CMS must allow granular management of SEO properties on a per-page basis in order to ensure good performance for the pages in external search engines, such as Google.
The CMS must include support for fundamental SEO functionality, such as meta description fields and site map generation.
Accessibility (REQUIRED)
The CMS’s frontend output must be able to natively support the technical requirements of web accessibility standard WCAG 2.1 or newer, Level AA, as well as any applicable national requirements, to ensure that from the technical perspective, the content is accessible to all website visitors, including those with visual or motor impairments.
Versioning (RECOMMENDED)
The CMS should support data publication workflows that allow content to be prepared without instantaneous publication. It should also have the possibility for publication processes involving multiple levels of review and approval before publishing.
The CMS should also include a detailed history function that allows reverting of published content and establishes an audit trail for all content.
Differentiated backend user permissions (REQUIRED)
The CMS must support differentiated group-based user permissions that allow a large number of editor users to access and manage only the content that lies within their purview. This is important both for security and governance.
Permissions should at least cover these areas:
Differentiation between view only and changing content.
Assignable access to websites, sections of websites, and individual pages.
Possibility to limit editing to particular content types.
Access to document and media storage structures within a more extensive digital asset repository.
Differentiation between view only and changing digital assets like documents and media.
Data import and export (REQUIRED)
The CMS must support bulk data import and export through a well-documented API or standardized and open file formats.
Data decoupling (RECOMMENDED)
The CMS should employ a high degree of decoupling (i.e., separation) between content data and view/design information.
6 Data Structures
Database — structured data storage and decoupling
The CMS should employ a high degree of decoupling (i.e., separation) between content data and end-user presentation. Most modern CMSs store content in structured form within a relational or object-oriented database, however, not all employ decoupled data.
Data decoupling will allow higher performance on operations involving extraction of more atomic data entities because they employ database queries, rather than searches within larger data blobs. Such extraction tasks could for example “all images on a page” or “extract all headings for a table of contents.”
Data decoupling will also allow more effortless reuse of data on other platforms, implementing the possibility of increased use of single redundancy in the data space.
Media files and documents — flexible locations and asset management
The CMS should support flexible referencing of files that allows for file storage in multiple locations, not necessarily on the hosting server. This enables efficient file storage, interaction with document management systems, and increased access security for vital files.
The CMS should support file taxonomy and metadata management, either within the core or with a deeply integrated digital asset management (DAM) system.
Configuration — versioned and differentiated by site and environment
The CMS should support configuration within versioned configuration files in a way that supports domain-dependent configuration. Configuration should be able to be stored outside of the database and should enable the use of different configurations for different sites and deployment environments.
Code — deployable and versioned, separate from data
All source code must be deployable separately to data in media files, documents, and databases. The CMS must thus support the implementation of replicable on-deploy upgrade functionality for differing data sets, for example, in development and live environments.
The CMS should support the use of a dependency manager, such as Composer for PHP, Maven/Gradle for Java, or NPM for JavaScript.
7 Implementation strategy for governments
National and institutional governance and regulatory alignment
The implementation of the CMS Building Block requires a cohesive long-term strategy that implies a framework of governance at the national level. This involves firm institutional alignment and assignment of institutional responsibilities for the lifetime of the governmental websites.
The specific strategy must be aligned with the national strategies, policies and regulations, as well as the guidelines that apply to government software development and procurement within the country, in particular those concerning websites and web services.
Sustainability through a long-term, comprehensive approach
The implementation of the CMS building block cannot be thought of only as a one-time development project involving the launching of several websites. It is imperative to the success of the project that the adoption of the CMS building block is implemented as a comprehensive and sustained effort. The methodology must be applied nationally, to all the websites of the government, and — to the extent it is feasible — to all other public institutions.
The national strategy must be built on at least these three pillars:
Standardization must be sustained for the entire lifetime of the government websites, as detailed in the prior chapters.
Digital sovereignty must be founded on the institutional capacity to manage the websites.
Sufficient local technical expertise must be available. Domain-specific experts will have to be employed at different stages, such as development, maintenance, upgrade, and content management.
Success factors for a sustainable and reliable result
Based on CMS building block implementation experience from diverse countries, a number of aspects are very relevant and should be implemented for a successful, sustainable and reliable outcome. The most critical elements are related to the project ownership and the institutional alignment.
Clear ownership and sponsorship
Website standardization is an important endeavor that requires active systemic change management. This requires an institutional owner managing all aspects of the project and an institutional sponsor supporting the implementation. Depending on the institutional ecosystem, these roles can be assigned to different institutions.
The project owner may be the ministry in charge of the digital transformation or the national agency mandated to execute the national digitalization strategy.
The project sponsor may be an institution responsible for the good governance of the country, such as the office of the president, the office of the prime minister, or another central body with a general mandate.
The cost of fragmented governance and infrastructure
Website projects for central institutions may already have been developed and deployed, leading to the presence of existing implementations, legacy processes, and technical approaches — even if central policies, regulations, or guidelines do not back them. In many countries, event transversal requirements and guidelines, such as graphic identity or web accessibility rules, are not centrally defined or enforced.
This decentralized project governance gives full autonomy to each institution, allowing them to define their requirements, technologies, suppliers, implementations, legal frameworks, and hosting. Institutions that already have dedicated personnel in their IT departments or that already own hosting infrastructure can be reluctant to cede their autonomy.
However, the fragmented approach leads to high cost, high risk, substantial management overhead, and inconsistent experience for the country’s website visitors.
Implementing necessary institutional alignment
Even without a history of fragmented website projects, existing structures may work against centralized institutional cooperation and alignment. Therefore, the establishment of a shared governance platform and institutional alignment through gradual evolution will often be required.
The following chronological steps exemplify a successful implementation process. Though proven to lead to the desired objective, the process is nevertheless no guarantee for quick or smooth progress. Other paths may be identified in the future.
Identify the long-term institutional owner of the project and the formal institutional sponsor.
Perform a stakeholder analysis on the national level, including:
Central institutions
The national technical ecosystem, that includes the private sector and academia.
Active/interested donors/supporters. This could include international organizations, development agencies, and NGOs.
Determine the feasible implementation approach for the first phase.
A Top-down approach, starting with ministries and central agencies. This is the ideal first phase.
A transversal pilot approach that standardizes a certain institutional domain first. This is best when facing difficulties with institutional alignment. Real-world experience has shown that it may be easiest to start with one of the following:
Regional and local administration
Diplomatic representations
Public hospitals
Benchmark, identify and clearly define the technology stack. Following the CMS building block specification, different technical platforms may be suitable. The benchmarking should cover the criteria described in this specification, as well as criteria considered by the country, in particular by the institution that owns the project.
Determine the status of the national technical policies, regulations, and guidelines. Do they need development, updating, or refinement? Policies and guidelines that could be covered include:
Graphic identity and user experience guidelines
Web accessibility regulations or guidelines
Cyber security guidelines
Rules related to the project management of technical projects, public procurement of technical services, quality assurance of technical projects, etc.
Establish the informational content presentation structure and the website content strategy, including specific requirements related to national must-have content, content structure reuse between multiple websites, standardized ways to present the content (content blocks or design elements), content management workflows, etc.
Establish and implement an action plan to ensure reliable and accessible technical capacity. Generally, the capacity should be developed through a combination of initial intensive training and on-the-job coaching. A plan for continuous expansion of capacity should be implemented, including training materials and training knowledge, through a train-the-trainers program. The training should include all relevant roles involved, in particular related to project management, technical implementation and maintenance, and content managers. The training should not be limited to the personnel hired by the public institutions
Involve the national digital ecosystem, including universities, local IT companies, and local developers. The involvement of non-governmental stakeholders enables a broadening of the technical capacity pool and wider adoption of practices and technology outside the public sector, securing long-term availability and accessibility of technical resources. The fostering of a national technical community can bring additional benefits in long-term sustainability of the technical talent pool.
Establish a permanent training and support program for the content creators and editors that are responsible with the content management of the CMS websites. The training process should be conducted by a central responsible training unit, based on training manuals and procedures. The content editors should benefit from permanent direct support in determining optimal content publishing approaches and content migration from old website versions, developed using legacy technologies.
Establish a support and maintenance process and assign responsibility for it. Government websites require permanent support and maintenance. Maintenance operations may include fixing errors, optimizing performance, developing new content blocks, installing and configuring new functional modules, developing new custom functionality, or applying patches made available by the technology provider. Maintenance operations should be subject to constant management and monitoring and should rely on permanently available technical specialists (employees of the responsible central institution or private local contractors, ideally both). Support-level framework agreements are a recommended contractual management approach. These are awarded competitively to at least one — but ideally multiple — contractors. Multiple contractors leverage potential resource availability bottlenecks.
Establish a software upgrade schedule and assign responsibility for it. Government websites require periodical upgrades of the underlying technology and server components to ensure security, performance, accessibility, user experience, and other improvements offered by new versions. The upgrades should be predictable, requiring planning, budgeting, and scheduling well in advance. Contractors and other important stakeholders involved in upgrades must be consulted early. Upgrades fall into different categories and frequencies:
Security upgrades and high-impact bug fixes are time-sensitive and must be implemented rapidly.
Functional additions and corrections
Minor and major upgrades should follow the software’s release schedule. Commonly every 9–18 months.
CMS instances usually benefit from a comprehensive review, reengineering, or replacement every 5–6 years.
Establish and follow a hosting strategy. Digital sovereignty is best achieved using a national data center controlled by the government, with a dedicated and well-trained team, available 24/7 for support, monitoring, and intervention.
Websites can be clustered in multi-tenant instances based on a grouping strategy (e.g., grouping together national government websites, hospital websites, etc.). This balances risk and maintenance effort.
The server software should be based on well-maintained and up-to-date stack.
Suspicious activity and attacks can be mitigated through continuous monitoring. A disaster recovery mechanism with off-server automated backup and specific recovery procedures should be implemented.
Dedicated servers should be available for different stages of the deployment and testing process (e.g., development and staging environments). Here modifications and updates to code and configuration can be tested in a close-to-real-life setting to ensure minimal downtime for the production websites.
Domain names should follow a coherent and well-documented strategy governed, controlled, and allocated by a central authority..
All websites should be secured with centrally managed and updated SSL certificates to maximize security and uptime.
Establish and follow a cyber security strategy. Even a minimal cyber security strategy should include procedures for security validation of CMS instances and servers, periodical security audits, and continuous monitoring. A rapid intervention capacity must exist and use clear operational procedures.
Establish and follow a permanent performance monitoring process. The performance of the servers and websites should be continuously monitored. Web page response times may be influenced by numerous factors. Decreasing performance should be investigated immediately and resolved through e.g., software or database optimizations, improved caching, or additional hardware resources.
Establish a continuous funding strategy. Funding the implementation and long-term evolution of the national project based on this CMS building block must be approached strategically. Multiple components are involved and a financial plan must determine the sources of funds and ensure that each component of the life cycle has sufficient budget allocated.
8 Synergies with other GovStack Building Blocks
The integration between the CMS building block and other GovStack building blocks can enhance the effectiveness of the project implementation and create a consistent experience for the end users with optimal use of technical infrastructure resources.
Such integrations should especially be aimed at the following building blocks:
Workflow: The CMS building block can offer access to e-services implemented using the Workflow building block. In G2C or G2B e-service delivery, the CMS can initiate a request through a web form determining the starting of a new process instance, retrieve the status of a request and deliver notifications. The CMS building block can also support the digitalization of G2G workflows through access-restricted web interfaces. Intranets can enable processes to be initiated through form submission, data verification, and approval workflows. In general, the CMS can provide the end-user interface for the Workflow building block.
Consent: The CMS building block provide online interfaces allowing the data subject (the user providing consent for the use of their data) to view data agreements and give or revoke consent.
Digital Registries: The CMS building block can offer online interfaces for accessing and querying digital registries. This includes the possibility of aggregating, processing, and analyzing data retrieved from registries, for example, through web-based dashboards.
Cloud infrastructure: The CMS building block relies on hosting infrastructure. Modern CMSs allow for fully automated, software-defined deployment across multiple environments.