Service Delivery Team Onboarding and Service Delivery Guide

Version 1.8

Version control table

Introduction

The purpose of this guide is to explain all the necessary actions that need to be taken and prerequisites that have to be met by a service delivery team to collaborate, develop and deploy a new service or a ‘bucket’ of services on the DSF infrastructure (currently an Azure AKS Cluster) using the DSF Service Standard and DSF Design System along with the actions to be taken concerning service fixes and iterations. A Service Delivery Team could be either an internal team (within the Government of Cyprus) or an external vendor (A private company collaborating with a Government Ministry/Department bound by a Framework Agreement for the Digital Transformation of Government Services or by any other type of government contract. The process of onboarding a service delivery team to successfully deliver a service or a ‘bucket’ of services is described in detail in the sections that follow.

The process of delivering a Service, in this document, is read as the “project”. 

Project Initiation Process

Before the implementation of the service, the Project Manager of the Contracting Authority shall fill in a Service Delivery Initiation Form (Version 1.3) for each service/iteration to be delivered. This form contains service basic technical information along with the targeted outcome (outcome-based approach).

All communication between the DSF Tech Team and the Service Team shall be initiated exclusively by a Governmental Technical Officer (Solution Integration Officer) and the technical DSF team. In the event of the absence of a Technical Officer, the role shall be assumed by the Project Manager. The email account dsf-tech@dits.dmrid.gov.cy will serve as the designated point of contact for the Tech Support Model.

The onboarding stage shall be initiated by a meeting of all stakeholders. If needed, other meetings can follow to communicate the goals of the project and identify the service’s boundaries by all parties involved. 

Initiation Stage

Following the onboarding stage described above, the Service Architecture Document shall be submitted by the Project Manager of the Contracting Authority to be reviewed by the Digital Services Factory (DSF) Team. A formal response by DSF shall be communicated back to all involved parties with an initial draft of a Service Delivery Roadmap.

A kick-off meeting between the DSF Team and the Service Delivery Team shall be arranged by the Project Manager of the Contracting Authority to officially initiate the project. Any issues, problems and clarifications will be discussed to align all involved parties with the goals. An agile project management approach shall be used, with sprint goals defined. Members from both teams, the DSF Team and Service Delivery Team, shall participate as needed in agreed-upon meetings to resolve possible issues.

Service Workflow Process

The service shall undergo the following workflow process as per the Service Standard: Service Design, User Research, Content Design, etc.

Using the DSF Infrastructure

Development Process

All development and deployment processes shall be done using the DSF Infrastructure.

Diagram 1.1

The source code of the service must be uploaded along with the relevant documentation (README file) and will be maintained on a per-project, pre-specified DSF Github Source Repository. Access shall be granted to the Service Delivery Team’s member(s) upon request.

CI/CD Pipeline

A per-service DSF CI/CD pipeline shall be configured and run to test, build and store the service container image in the DSF’s Github Container Registry (ghcr.io,  see Diagram 1.1). It is the responsibility of the Service Delivery Team to have a successful build of the project as a container image using a Docker file in the root folder of the repository.

The service shall be deployed on the DSF’s Azure Kubernetes Service (AKS) cluster, initially on the DSF’s Infrastructure Staging Environment, using a configuration script (number of pods, # of vCpu,  RAM etc., performance and CPU intensity info shall be needed to be provided from the service team’s part to size the pods appropriately).

Later, during the testing process (see. the Testing Process section in this document), a performance and analytics tool shall be used to better assist with the final sizing of the service pods (A “Pod” is a service instance that runs on the AKS cluster; A service can have more than one pod running for high availability and performance).

Authentication Requirements

If Citizen/User authentication is required by the service, authentication requirements shall ONLY be fulfilled through CY Login authentication service using the CY Login access token to access the required data.

Notification (SMS & Email) Requirements

If citizen notification (either by email or by sms) is required by the service, Notification requirements shall ONLY be fulfilled through CY Notification. To use the Notification Service, a “Notification Client Account” (provided by the CY Login Team) is required for each deployment environment (Production and Development).

Payment Requirements

Citizen payment requirements shall ONLY be fulfilled through CY Payment. To use the Payment Engine, a “Payment Client Account” (provided by the CY Login Team) is required for each deployment environment (Production and Development).

Data Access and Storage Requirements

Any data access or data storage requirement shall be handled by the service delivery team’s end, using or developing a backend API (shall be developed by the Service Delivery Team or by the Backend’s Support Team based on the requirements scoped for the service) and shall be exposed to CY Connect for the service to have access to. The DSF API Standard must be followed when developing the service api.

Diagram 1.2

Domain Name Registration Process

A service name shall be provided to the DSF tech team to register the Domain Name of the service. All DSF-hosted services shall have qualified names under these two domains: 

1. <service_name>.service.gov.cy for the production, ie.do-a-thing.service.gov.cy and 
2. <service_name>.staging.service.gov.cy for the staging environment, ie. do-a-thing.staging.service.gov.cy 

For naming the service and the service’s end-point URLs please refer to the “Service name and URLs” section of the ‘Content Design Standards for Services. 

Testing Process

Testing shall be conducted by the Service Delivery Team as needed on the DSF’s Staging Environment  (DSF-SE). It is the service team’s responsibility to conduct all necessary tests, including UAT (User Acceptance Test), unit tests, performance and load/stress testing. A WASA (Web Application Security Assessment) should also be conducted before the service is sent to DSF for Quality Assurance assessment. The WASA must be performed by an independently certified penetration (PEN) tester, preferably with relevant experience. The PEN Testing results report shall be disclosed along with the Data Protection Impact Assessment (DPIA) report to the Personal Data Protection Commissioner.

When all the necessary tests are performed successfully, the service shall be available for the quality assurance assessment.

Assurance Process

The service shall undergo the DSF assurance process to proceed with the deployment process.

Deployment Process

The deployment of the service to the DSF Production environment is carried out by the DSF Tech Team. The Service Delivery Team must inform the DSF Tech Team of the intended Production deployment date and time at least 7 working days in advance. Any changes to the agreed Production deployment date must also be communicated to the DSF Tech Team. The deployment to the Staging environment is also carried out by the DSF Tech Team. Staging deployments can take place as early as needed; however, the Service Delivery Team must allocate and plan for 5 man-days for deployment preparation and execution. Additionally, please note that deployments in both the Staging and Production environments will not take place on Fridays or the day before public holidays.

Going Live

It is recommended that when the service goes into production, a ‘controlled release’, usually a week’s duration, is introduced. The ‘controlled release’ precedes the full ‘going live’ phase, and it is a non-advertised production use of the service by a pre-selected group of users/citizens that are eligible to use it to test the whole end-to-end process in the actual production environment. All citizens’ applications/requests during this phase shall be officially processed, and all the outcomes shall be considered valid. After assessing all outcomes of the “controlled release” by the service team,  the service shall be advertised and published on the “gov.cy” portal for full public access.

Managing vulnerabilities is crucial for the security of the DSF infrastructure. The service owner is responsible for identifying and resolving vulnerabilities in the GitHub repository. Dependabot is a GitHub tool that automatically scans your repositories to ensure they remain current and secure. 

Critical vulnerabilities must be addressed within the timeframe indicated in the table below. The issue will be escalated if the service owner fails to address these vulnerabilities within the specified timeframes. The escalation will involve immediate notification to the DMRID security team to ensure swift action is taken. This escalation process ensures that security issues are addressed promptly.

After all vulnerabilities are resolved and retested on the staging environment, the service owner shall send a request to the DSF Tech Team, via email, for redeploying the service to Production (service image version, “Digest” – hash value, must be included in the request). 

Timeframe table for vulnerability resolution: 

Vulnerability Severity	Timeframe for resolving
Critical/High	Within 30 days of initial detection
Medium	Within 60 days of initial detection
Low	Within 90 days of initial detection
Informational	No specific deadline unless defined

Project Closure

Project closure is reached when all project requirements are met, including receiving the final “Service Standard Verified” seal.

Service fixes and iterations

Any service fixes/iterations performed by the service team shall be communicated to the DSF Team by the Project Manager of the Contracting Authority.

The Project Manager of the Contracting Authority shall request a redeployment of the updated service by providing adequate documentation with reference to the Assessment Report Number of the service and describing all new service fixes/iterations performed on the service (an updated service CHANGELOG file shall also be included in the request). Upon reviewing the request, the DSF Assurance team shall respond with a direct order for re-deployment or with a request for a new service assessment. In the case of the latter, the order for redeployment shall be given based on the assurance result.

After acceptance from the Contracting Authority of any service fixes/iterations issued by the service team, they shall be communicated to the DSF Team (dsf-qa@dits.dmrid.gov.cy) via the Project Manager of the Contracting Authority.

The Project Manager of the Contracting Authority must send the files, including a CHANGELOG file for documentation on the bugs/fixes/iterations, to the DSF Assurance Team. The DSF Team will handle each request accordingly and decide whether a new assessment is required before deploying the fixes/iterations of the service. The deployment procedure is as described in the Deployment Process above.

Additionally, the service owner must notify DSF (dsf-tech@dits.dmrid.gov.cy) to release the associated GitHub licenses, in case there is a change regarding the repository access of suppliers and/or other stakeholders to ensure continuous compliance and protection.

Follow the DSF Deployment Guide for step-by-step instructions (summarised below) on deploying your digital service to the staging and production environments.

1. Fill out and submit the Service Initiation Form to dsf-tech@dits.dmrid.gov.cy.
2. Contact the CDS team (cds-support@dits.dmrid.gov.cy) to:
   • Request CyLogin, CyConnect, CyNotify, CyPay (if needed)
   • Exchange technical configs (API keys, callback URLs, etc.)
3. Accept GitHub repo invitation from DSF.
4. Clone the repo and push your code to the main branch.
5. Create a Dockerfile in the repo root.
6. Prepare staging secrets file (e.g. .env, appsettings.json)
   • Include Matomo IDs, CDS credentials, etc.
   • Do not commit this to GitHub.
   • Send it securely to DSF.
7. Notify DSF that Steps 1–6 are done (at least 3–5 days before staging deploy).
8. Wait for DSF to deploy to staging and confirm the service is live.
9. Set up GitHub Actions for automated staging deployments.
10. Push code updates to main for re-deployment to staging.
11. Test your application on staging (UAT, functionality, performance, etc.).

---

12. Schedule WASA (security test) via Contracting Authority.
13. Fix vulnerabilities, push to staging, and repeat WASA if needed.
14. Get official WASA approval.
15. If applicable, complete and submit a DPIA report.
    • Get it approved by the Data Protection Commissioner.
16. Prepare production secrets file (separate from staging).
    • Share securely with DSF.
17. Identify SHA digest of the approved Docker image from staging.
18. Send DSF the SHA digest, production secrets file, and approvals.
19. Wait for DSF to manually deploy to production.

---

20. Maintain a clean and detailed README.md in the repo.
21. Maintain an up-to-date CHANGELOG.md with version history.
22. Monitor and resolve vulnerabilities using GitHub Dependabot.

Relevant Content

• User Satisfaction Page Guide
• Matomo on-premise
• DSF Onboarding and Deployment Guide
• Testing Process for a Digital Service
• Design System