Documenting environments and architecture

We develop on a supported WordPress and server environment with separate development, acceptance and production environments. The architecture document records which elements are standard, where custom development is needed and which external services are used. This allows Chrysal to assess the consequences of a choice before it commits to costs.

The website will be designed for desktop, tablet and mobile. We target the Core Web Vitals benchmarks for real users: LCP no more than 2,5 seconds, INP no more than 200 milliseconds and CLS no more than 0,1 at the 75th percentile, where sufficient field data is available. These values are design and optimisation goals; before go-live, we use repeatable laboratory tests on representative page types. [12]

Hosting, caching and image optimisation

Hosting, efficient components and image optimisation work together in this. Varnish handles page caching where appropriate and Memcached handles object caching. Cloudflare can serve static content closer to visitors as a reverse proxy and CDN. We prevent conflicting cache layers and exclude forms, logged-in sessions and future shopping baskets or checkouts where necessary. An editorial change must refresh the correct caches, including for local variants.

Performance on rich pages

For example: a rich knowledge or case page receives appropriate image formats, reserved image space and limited script loading. A video does not automatically start as a large download on a mobile connection. We provide a performance report and specific limits for media use, so that editors can maintain quality after delivery.

We propose WCAG 2.2 level AA as the development and testing standard. Accessibility starts with semantic HTML, keyboard operation, visible focus, contrast, form labels, error messages and usability when magnified. This aligns with the current W3C guideline. [8]

Testing accessibility in processes

The accessibility plugin developed by Afdeling Online, as mentioned in the brief, can be used in a supporting role where its specific functions are suitable. A plugin does not automatically make a website compliant. We combine automated checks with manual assessment of representative pages and complete processes, including search, language selection and contact. Existing PDFs and external widgets are inventoried separately; their remediation is assigned a separate scope. Recommended includes a budget for an independent sample audit and remediation of findings within the agreed development scope.

Accessible form as an example

One example is a technical form that must be fully usable without a mouse. The user receives understandable error messages, can reach the error directly and does not lose entered data. We provide a test report with the scope, results and any remaining limitations.

For forms, cookies and external services, we create an overview of data and services. Together with Chrysal’s privacy officer, we determine purposes, legal bases, retention periods, recipients and necessary data processing agreements. We work with clients using both CookieYes and Cookiebot. CookieYes is the platform we use most often and our proposed first choice for Chrysal; Cookiebot remains an alternative if Chrysal’s existing setup or requirements make it more suitable. We confirm the platform, plan and licence costs before commissioning. We configure categories and blocking and test whether tags behave as agreed before consent, after refusal and after withdrawal. As a baseline, we assume no analytics or marketing requests before the required consent; a different configuration is chosen only after an explicit privacy assessment. Consent choices are presented understandably and without pre-ticked tracking. [13, 14]

Aligning cookies and privacy texts

We inventory which cookies and requests actually occur, including embeds and forms. A privacy statement and cookie declaration are aligned with this. Where Afdeling Online has legally reviewed template sections available, these can serve as a starting point; their applicability and currency are checked for Chrysal. The privacy officer approves the final texts and configuration. Neither CookieYes nor Cookiebot, Consent Mode or server-side tagging in itself constitutes proof of compliance.

Data minimisation in technology

On the technical side, we minimise data, use encrypted transport and appropriate access rights and prevent personal data from appearing in analytics and URLs. For international services, we assess data location and transfer. One example is a technical advice form: only data needed for follow-up is mandatory; newsletter subscription is a separate choice. These choices are documented in the measurement and privacy dossier.

We propose a security setup with multiple layers. Cloudflare sits in front of the hosting as a reverse proxy, with an appropriate firewall configuration, protection against automated abuse and rate limits. The capabilities depend on the chosen service plan. Where technically possible, the origin server accepts traffic only via the agreed routes. TLS, secure headers, input validation, access control and restricted permissions are applied in the application. An appropriate security plugin supports logging, login security and checks in WordPress. [15]

Securing access, updates and backups

Administrators use personal accounts and MFA; users receive only necessary permissions. Extensions are selected based on maintenance, functionality and risk, after which updates are tested through the acceptance environment. Access to backups and keys is restricted; secrets are not stored in public code. Forms receive protection against spam and abuse with attention to accessibility and privacy. Cloudflare and a plugin reduce risks, but do not provide an absolute security guarantee.

Following up on and evaluating incidents

An incident is followed by triage, impact containment, recovery and evaluation. We inform the designated contacts and provide available facts for any follow-up steps by Chrysal’s privacy officer. The services and responsibilities are detailed in chapter 17.

We limit the number of dependencies, document custom development and keep implementation and configuration under version control. The handover dossier contains the stack, licences, interfaces, release procedure and known limitations. During discovery, we investigate CRM, analytics, marketing platforms, product data, DAM, recruitment and distributor or location systems. For each integration, we identify the source owner, interface, synchronisation direction, error handling, security, costs and business benefit.

E-commerce with its own architectural path

E-commerce is explicitly given an architectural path. Product and solution content receives stable identifiers, while prices, stock, transactions and regional terms can remain in a commerce environment. An initial webshop can connect via WooCommerce or an existing regional platform. Beforehand, we investigate matters including legal entity, VAT, currency, language, product range, payment, shipping and potentially ERP. A complex B2B price list or order integration is not implicitly included within a simple webshop module.

We propose daily encrypted backups of the database, files and configuration, retained for at least thirty days and with a copy outside the primary production environment. A backup is also made before relevant releases. We test recovery at least quarterly. For the content platform, we propose an RPO of 24 hours and an RTO of eight service hours: the maximum targeted data loss and targeted recovery time, depending on the incident and supplier availability. For a future webshop, we assess a shorter RPO because of transactions.

Certification only with evidence

We organise access management, change logging, incident handling and continuity according to demonstrable controls. If ISO 27001 certification of Afdeling Online or a supplier is cited, a valid certificate, certificate holder, scope and expiry date are provided in advance. This proposal does not assume any unconfirmed certification as fact. A backup alone does not prove ISO compliance.

The test matrix includes current supported versions of Chrome, Edge, Firefox and Safari on desktop, Safari on iOS and Chrome on Android. The exact versions and devices are recorded at the start of UAT and checked against existing visitor data. We check functions, content, translations, search results, permissions, interfaces, consent, accessibility and performance.

Resolving findings before go-live

We provide test results and a list of findings. Critical and high-severity findings that block core tasks must be resolved before go-live. For smaller findings, Chrysal may explicitly accept a remediation schedule. An end-to-end test checks, for example, whether a mobile visitor in the correct market finds a solution, submits an enquiry, receives a confirmation and reaches the right employee.