Objective

This document focuses on deciding whether Personal identification information collected in each rainmaker module is used for data security and privacy purposes.

Target Audience: This document is intended for Engineering (tech team), Product Management and Implementation team to agree on requirements for data privacy and data security.

Introduction

As a product provider to the government, we should be responsible for the data security of individuals and organizations who are using our products. The first step in data privacy and security is to identify personal identification information (PII) which will then decide our approach to data security. The personal identification information listed in this document is decided with the help of ‘WHITE PAPER OF THE COMMITTEE OF EXPERTS ON A DATA PROTECTION FRAMEWORK FOR INDIA’. The remarks and provisional views of the committee are given below:

Justice Srikrishna Committee On Personal Identification Information (PII)

All information about an individual is not personal data. As stated earlier, the protection of identity is central to informational privacy. So the information must be such that the individual is either identified or identifiable from such information. In statutes or instruments which use both these terms “identified or identifiable” such as the EU GDPR, it refers to states in which the data can exist. Data could be in a form where individuals stand identified or in other cases, it is possible that they could be identified. Whether an individual is identifiable or not is a question of context and circumstances. For instance, a car registration number, by itself, does not reveal the identity of a person. However, it is possible that with other information, an individual can be identified from this information.

Provisional views of the committee on Personal Data:

1. It is data about/relating to an individual that may be the subject matter of protection under the law. Data in this context ought to include any kind of information including opinions or assessments irrespective of their accuracy.

2. Data from which an individual is identified or identifiable/reasonably identifiable may be considered to be personal data. The identifiability can be direct or indirect.

3. New technologies pose considerable challenges to this distinction based on identifiability. This standard may have to be backed up by codes of practice and guidance notes indicating the boundaries of personal information having regard to the state of technology.

On the basis of the above comments potential information from rainmaker modules i.e. PGR, PT and TL were identified and the storage of information in each module was analysed as below.

Terms Used & Definitions

1. Primary PII: With the help of given information individual can be directly identified

2. Secondary PII: With the help of given information an individual can not be identified directly but an individual can be identified if this information is available with one of primary PII.

3. Independent PII: With the help of given information individual cannot be identified directly but this information can help the receiver to identify an individual through other means like search for property tax/ trade license or electricity connections

4. Sensitive info: Password, Gender, Bank account number is sensitive information which needs to be protected

Module-wise data points required to secure are given below:

PGR

Trade License

Property Tax:

Water & Sewerage

OBPAS

Fire NOC

mCollect

HRMS

Finance

Decryption Service:

1. Role-based decryption with the jurisdiction of employee

2. Service-based decryption for citizens. Example: billing and collection service

Bulk Search in every Module:

1. Search should not be enabled for citizen

2. Bulk search in any module should not show more than 10 entries at a time

3. PII should be masked in search results

4. Employees can request to view PII in this case

   • The declaration should be made by the employee: about ethical use and

   • The entry should be audited with the Name and Mobile number of the employee

   • Notification about audit entry to the viewer

Scope

DIGIT, an open-source platform, provides a citizen-facing service delivery system in urban governance, sanitation, health, and public finance management.

As citizen data is collected and used for such governance services, data privacy and protection measures are required to ensure this data is managed responsibly and safely.

This document is created to be an online guide, providing guidelines for platform owners (providers of DIGIT-like systems) to maintain data privacy and protect individuals’ data.

• Readers can use this to identify the steps they must take as platform owners or providers to ensure data privacy and protection in the context of a DIGIT or DIGIT-like implementation.

• It can also provide source material for privacy policies, which should be included in each portal & application.

• This is not a technical reference or documentation. It serves as a policy guideline.

References made to DIGIT are also applicable to other platforms similar to DIGIT. Not all parts of the guidelines or featured content may match the reader's platform, hence this document is open to be referred to in parts as needed.

Basic Terms & Definitions

What is data?

Data is the information collected from an individual or about an individual. In DIGIT, data can be any information pertaining to a citizen, which is required for delivery of service and/or information exchange flow amongst citizen, employee, vendor and administrator. Data and information are interchangeably used.

What is data security?

Data security is the act of securing and safeguarding data. Active measures are taken to protect the data from misuse or harm. Such actions can be pre-emptive i.e. security steps taken before the data is collected or the actions could be reactive i.e. steps taken after the platform has been set up. DIGIT recommends pre-emptive steps as a best practice, and has data security measures embedded within its design.

What is data privacy?

Data privacy means keeping the data in the control of the individual and allowing the individual to decide what is to be done with their data. Data that is collected or shared without the consent of an individual, especially when exposed and combined with other data points, can cause citizens to be identified and targeted. That’s why protecting data indirectly protects the citizen as well.

Data Privacy requires protecting the data from unwarranted viewing, use, or sharing. This involves taking steps such as data minimisation (only collecting and storing data that serves a defined purpose), encrypting data, restricting access to the data, and/or masking what data is visible to users. DIGIT is designed to maintain the privacy of citizens and protect data by taking all the steps mentioned above and more.

What is personally identifiable information (PII) or personal data?

PII stands for personally identifiable information or is also interchangeably used as personal data.

Personal data is defined under the Digital Personal Data Protection Act, 2023 DPDP Act at Sec 2(t) - “personal data” means any data about an individual who is identifiable by or in relation to such data

Personal data is basically any information that makes a person identifiable. This consists of data that is unique for each person. When it is combined with other forms of data, it can help in identifying a person. For example, our biometric information, credit card details, passport details etc. are all PII.

What is a personal data breach?

The DPDP Act at Sec 2 (u) states that “personal data breach” means any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises the confidentiality, integrity or availability of personal data

A personal data breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of, or access to, personal data. This includes breaches that are the result of both accidental and deliberate causes. It also means that a breach is more than just about losing personal data.

Personal data breaches can include:

• access by an unauthorised third party;

• deliberate or accidental sharing of data, or of credentials that enable access to data, with an unauthorised person by a handler, collector or processor;

• sending personal data to an incorrect recipient;

• computing devices containing personal data being lost or stolen;

• alteration of personal data without permission; and

• loss of availability of personal data.

Both the above definitions can be read together, but the definition given in the DPDP Act would get a preference in case of a conflict.

What kind of data does DIGIT handle?

The DIGIT platform does not handle data unless and until it is implemented in a particular context. Each implementation of DIGIT handles a combination of non-personal data and PII; the latter may further be classified into data which, in itself, identifies the individual to whom it pertains (“identified”) and data which, if combined with other data, can identify the individual to whom it pertains (“identifiable”)[3].

B1. Personal Data / PII Of Residents/Citizens

Specific data recorded in various applications that may be implemented on DIGIT include name, parent/spouse’s name, mobile number, city, email id, date of birth, door no/address, and pin code. Data from administrative record systems, such as revenue survey number or other property identifier, connection number, meter number etc. may also be recorded. In the event a person makes payments to the local government, information related to the payment, such as transaction number may also be recorded.

Any personal data collected and stored in DIGIT is encrypted, both in storage and transmission. When displayed, this data is to be masked by default. Users can request to unmask data; if they have the appropriate authorisation, they will be able to view the unmasked data, and this request to unmask will be recorded in an audit log.

DIGIT implementations are used to provide government services to residents of a given city, town, village etc. The data collected, as described above, are necessary for the delivery of such services. When a resident approaches their local government for a particular service, they can be required to share, or allow access to, the information necessary to provide that service.

B2. Personal Data / PII Of Employees

DIGIT implementations also collect, store, process, and share information pertaining to employees of local government or other government agencies. Specific information can include name, age, gender, details of spouse or dependents, address, administrative details such as employee ID or other reference number, as well as information on bank accounts (used for processing salaries or pensions).

As employers, local governments may be required to maintain certain information on their employees and pensioners for tax purposes, such as PAN numbers; this information may be recorded and shared as well.

B3. Non-Personal Data

DIGIT implementations may derive, store, process, and share transactional data, which describes the progress of any ongoing task (e.g. any service requested by a resident) through the systems of the local government or other government agency. This can include information about the specific role to whom a given task is assigned (or with whom it is pending), the amount of time elapsed on processing / completing a given request (or task / sub-part thereof), and whether this task has been completed within the benchmark or designated amount of time. It can also include details about the channel through which a particular request was received, such as the ULB counter, service centre, website, helpline, mobile app, chatbot, etc.

DIGIT implementations may derive, store, process, and share aggregated data. These aggregates are derived from the transactional data. This includes data such as aggregate or cumulative revenue collection, aggregate or cumulative number of service requests, percentage of requests resolved within the benchmark time period, etc. The above data may be further analysed and presented in terms of the type of collection, request, or complaint, the channel through which it was received, etc.

DIGIT implementations may collect, store, process, and share telemetry data, which studies how much time is spent on a given screen or field in a workflow/user interface (UI). Such data is normally processed and shared in aggregate, and not used to identify specific individuals. In the event that specific individuals are sought to be identified, such as for user research, their consent will be sought for the further processing or sharing of their data.

B4. General Compliance With Legal Obligations & Global Best Practices

DIGIT is designed to enable compliance with requirements under Indian law, as well as global best practices, as follows:

• The requirement for a legal basis for the collection, storage, processing, use, and sharing of such data is fulfilled by the mandate of the local government or other government agency to provide a particular service.

• The requirement of a legitimate purpose is also met by the mandate of the local government or other government agency to provide that particular service.

• The requirement of proportionality is generally met by only collecting or accessing such data as is necessary for providing that particular service. This is also in line with the global best practice of data minimisation.

• The requirement for safeguards is generally met by the security and privacy measures, such as encryption and masking, described above; it is further met by implementing role-based access controls, which are aligned with the global best practice of differentiated access.

• The requirement for safeguards is further served by providing itemised notice, and by enabling any person to view what data of theirs has been collected/processed/shared (including the purpose for such collection/processing/sharing). Such provision of notice and visibility is further in line with global best practices of notice & user control. Such notice can only be provided in the context of a DIGIT implementation, and eGov provides a draft privacy policy to implementing entities.

• With respect to employees and pensioners, the requirements for legal basis, legitimate purpose, and proportionality are generally met by collecting, storing, processing, using, and sharing only such information as is relevant for assigning roles and administrative responsibilities, processing salaries or pensions, and completing any mandatory tax-related reporting.

Who Handles Data In The DIGIT Lifecycle?

The datasets flow from a point of service (POS) device to the integrator system, and from the backend of the integrator system to the DIGIT platform.

Data may be entered into a DIGIT registry or database in one of four ways:

• A citizen directly enters the data into a web portal, application, chatbot etc., as part of requesting government services.

• A local government or other government entity employee or contractor may enter the data into the system on their allocated device (computer at the service counter, mobile application in the field, etc.), as part of their work in providing government services.

• Data is migrated/ported from some previous systems, including paper-based systems, especially during the initial setup of the DIGIT-based system. This is also known as data migration.

• Data is shared in digital formats, such as through APIs or machine-readable spreadsheets, from some other system or platform to a system running on DIGIT.

Each module in DIGIT has different departmental employees feeding data at the field level.

These roles and their levels of access are determined by the administering authority (typically a local or state government), as part of the initial setup of the DIGIT-based system.

Existing roles may be modified and new roles may be created by persons who are authorised to act as system administrators following the initial setup. This means that the administering authority (or a person delegated this power by the administering authority) recognises these roles, and provides them with login credentials to access and collect citizen data for delivery of government services.

Examples of such roles that are recognised by our platform are: “EMPLOYEE","CITIZEN",”DOC_VERIFIER",”FIELD_INSPECTOR",”APPROVER","CLERK".

In any given implementation of DIGIT, the administering authority (local or state government) is understood to have responsibility for the data and is treated as the main data fiduciary with respect to the data of residents that is collected, stored, processed, used, or shared through or by the DIGIT-enabled tools or systems in use in its jurisdiction.

The primary responsibility for ensuring compliance with legal obligations and best practices with respect to data security, data protection, and privacy is thus that of the administering authority. To the extent that any other party (including eGov Foundation) serves as an agent of the administering authority, they are similarly considered responsible for ensuring such compliance, to the extent relevant to the tasks that they are performing.

Guidelines

These guidelines are to be read through the eyes of specific roles in the journey of adopting a DIGIT-based system or platforms similar to DIGIT in a government entity/ies. For each such ‘role’, a reader can follow its tasks in a given stage of implementation of DIGIT or such platform, and the guidelines associated with that task and stage.

It is to be noted that similar guidelines can be found for ‘data controllers’ under the General data protection regulation of Europe. There are a few basic and minimum requirements that data controllers (bodies that decide the purpose for processing data and the means used to process the data) have to comply with to ensure data protection by default (DbD and PbD) and design (data minimization, implementing safeguards for protection of data, controlled access to data, limited purposeful storage, etc). In Europe, entities are legally obligated to maintain DbD and PbD or else they are heavily penalised.

D.1 Guidelines for all roles

There are a few common guidelines that all roles in the platform implementation process must follow.

Data security measures and practices stand out as the core / foundational guidelines to follow for all roles.

DPP is only possible when the systems and computer resources receiving and storing data are secure (safe from any harm). Some key data security measures include:

• Access control: Establish audited and controlled access for personally identifying data, including authentication and authorization mechanisms. Authorize individuals only if they have a legal basis and a legitimate purpose to access the data.

• Encryption: Encrypt PII data both in transit and at rest to protect it from unauthorized access and theft.

• Data backup and disaster recovery: Regularly backing up PII data - including auditing the need for PII - if not required then deleting the PII, and implementing disaster recovery plans to ensure that important data can be recovered in the event of a data loss or breach.

• Network security: Implement firewalls, intrusion detection and prevention systems, and other network security measures to protect against cyber threats.

• Vulnerability management: Regularly scan for vulnerabilities and patch systems and applications to minimize the risk of a breach.

• Employee education: Educate employees/contractors/personnel on the importance of data security and provide training on best practices for protecting PII.

• Physical security: Implement physical security measures, such as access controls and video surveillance, to protect against unauthorized access to data centres and other data facilities.

• Third-party security: Carefully vet third-party vendors and service providers, to ensure that they have appropriate security measures in place to protect PII.

• Incident response: Develop and test incident response plans to ensure that the organization can quickly and effectively respond to a security breach.

• Compliance: Adhere to relevant security and privacy regulations, such as the IT Act, 2000, and its subsequent amendments and Rules. Conforming with standards such as ISO 27001 is also a good practice.

D.2 Detailed Guidelines for Platform Owners

The roles we cover under these guidelines are that of:

• Platform Owners (any individuals or body that creates and owns the platform which facilitates/enables the governments to provide for delivery of service)

The next document in this series covers the following stakeholders -:

• Administering authority (AA) (the entity that is mandated to provide for the government service usually an agency or department of the State government). This can include bodies like the State Program Directorate and Program Monitoring Units.

• Implementation agency (IA) / system integrator (the entity that implements the platform provided by the platform owner into the administering authority’s IT and operational systems).

• Support agency (SA) (the entity that may be involved after the platform is implemented, to maintain the system and provide support/troubleshooting.)

To understand what each role should do to safeguard DPP, it is important to understand what these roles do at each phase of the implementation of DIGIT.

D.2.1. Stage 0 -Program set-up

What is a program?

A program can be a delivery of any government service/s which the AA is mandated to provide to citizens for which it requires a platform. Defining the scope of the program is within the power of an AA.

D.2.1.1 What happens at this stage?

• A Memorandum of Understanding is signed between the AA and the platform owners

• State Program Head/Nodal Officer Appointed by the AA

• Resources and funding for the program are identified.

• The AA-specific procurement process is defined.

• IA team onboarding initiated.

D.2.1.2 Platform Owner at Stage 0 -

• Share specifications for man-power and infrastructure

• Program setup best practices are shared

• Enablement for product, configuration, infra

D.2.1.3. To-Do’s:

Operational:

• Any kind of agreement to be signed between the platform owners and the AA (e.g. an MoU) must have clear terms of data management, liability, and governance.

• Inform and clearly explain the platform’s in-house data practices and in-design DPP policies and practices of the platform to the AA.

• Create and maintain data use agreements with the AA (points on the legal framework for data access, what is to be done of the data and security controls are agreed on)

Advisory:

• Encourage and guide AA to adopt Privacy by Default

• Encourage AA to include DPP-enabling tech/non-tech resources in infrastructure resource planning. ( For eg - budgeting and reserving resources for data privacy impact assessments on the modules to be deployed)

• Encourage and guide the AA team in creating their data privacy and protection policy

• Identify the risks and necessary measures with the AA to ensure that any present or future data processing conducted by the AA is safe by design of the platform (Conduct data protection impact assessment)

• Guide and assist AA’s in training their employees in DPP practices

• Platform team to write a pre-mortem – an imaginary article looking back from the future on the feature’s perfect launch or failure – to help the AA and IA to focus on the privacy aspects that will ensure success.

• Encourage the AA to appoint privacy and data security-compliant Implementation teams or IA’s.

Technical:

• Do not offer any service module unless it is not compliant with relevant data privacy and protection (DPP) checks/standards and systems (see checklist in Appendix B of this memo)

D.2.2 Stage 1 - Program kickoff

D.2.2.1 What happens in Stage 1

• Publishing of the program charter and implementation plan.

• Master data collection kickoff in Pilot ULBs

• Cloud Infrastructure is procured

• Program branding is done (name, logo, tagline etc.)

D.2.2.2 Platform Owner’s Role in Stage 1

• Guide and review manpower, infra and program governance structure. Provide a stable platform version.

D.2.2.3 To-Do

Operational:

• Assist and encourage the AA team in setting a standardised data collection framework (with DPP practices like minimum personal data collected, masking of data, providing clear and simple notice to residents.)

• Assist the AA and IA teams in placing DPP principles and practices in the program charter

• Implementation kick-off workshop must include training in DPP practices ( minimum data collection, masking at field level, etc.)

• Encourage field-level ULB data collection team to inform residents about what data is collected and for what purposes

Advisory:

• Encourage the AA team to keep DPP as a priority in the implementation plan

• Advise the AA teams to collect as minimal data as possible to comply with the data minimisation principle ( at the master data collection level)

• Encourage within the AA employees, the behaviour of adopting privacy enhancing technology (PET). Highlight the increase of trust and reputation through the adoption of PETs’.

• Encourage IA to comply with data principle practices enlisted here.

Technical:

• Procured cloud infrastructure providers must be reviewed for DPP practices/compliance, especially around retention periods, access logs, and incident/breach management.

D.2.3 Stage 2 - Solution Design

D.2.3.1 What happens in Stage 2

• Standardized ontologies (uniform terminology for easier understanding), processes and workflows are created.

• Master data collected in the desired format.

• Agreement on program-specific product customisations is required.

• A detailed program plan is made and the tracking mechanism is finalised.

D.2.3.2 Platform Owner’s Role in Stage 2

• Guide and review the platform's extension/customisation, data collection/migration and accepted best practices.

D.2.3.3 To-Dos:

Operational:

• While standardizing processes and workflows, encourage the AA andIA teams to conduct a Privacy Impact Assessment (PIA): To identify PII that is being collected, processed, and stored, and to assess the risks associated with these operations. This will help identify any privacy issues that need to be addressed in the workflows.

• Develop privacy policies and procedures that outline the AA’s / program’s commitment to data privacy, and specify the measures that will be taken to protect personal data. These policies and procedures should be integrated into the workflows of the modules.

• Train employees on data privacy principles, such as data minimization and privacy by design. This will help ensure that they are aware of the importance of protecting personal data and the measures they need to take to do so.

• Assist the AA and IA in designing a clear data breach response plan (sets out procedures and clear lines of authority for responding to data breaches)

• Any changes or additions requested by the AA team that are contrary to any of the data privacy and protection regulations or principles must not be agreed to.

Advisory:

• Advise to regularly monitor and audit workflows to ensure that privacy policies and procedures are being followed and that personal data is being protected. This will help identify any areas where improvements can be made to ensure that data privacy is embedded in the workflows of the organization. Create a role that does the above.

• Assist the AAs in updating policies and procedures: Regularly review and update privacy policies and procedures in response to changes in technology, and data privacy regulations. This will help ensure that the state stays up-to-date with best practices for protecting personal data.

• Advise maintaining a data security ISO standardization as a prerequisite (ISO 27001 is recommended)

• Encourage the AA team to create strict access to workflows (login-based access, with access logs and periodic audits)

• Encourage better privacy by design customisations (for eg, masking from the point of collection)

Technical:

• Implement privacy-enhancing technologies (PeTs), such as encryption, anonymization, and access control systems, to protect personal data. These technologies should be integrated into the workflows of the module to ensure that personal data is protected throughout its lifecycle.

D.2.4 Stage 3 - Customisations and Configuration

D.2.4.1 What happens in this stage?

• A configured/customized product is created that is ready for UAT ( User acceptance testing).

• Monitoring Reports and Dashboards are ready ( to understand the rollout of the modules).

• Product artefacts like user guides are created.

• Identification of participants for the UAT session.

D.2.4.2 Role of Platform Owner in Stage 3

• Guide and review architecture, solutions and UX.

• Support in the configuration/customisation processes

D.2.4.3 To-Dos

Operational:

• Create user guides to maintain privacy as default (e.g. Appendix B in this memo can guide compliance with privacy principles.)

Advisory:

• Advise for privacy by default features to be adopted

• Guide in the protection of hardware from security threats

• Ensure and assist the AA in making sure that all access controls have been set up

• Advise the state to include data privacy and protection checklist questions in the UAT phase

• Guide and assist the AA and IA in creating anonymised testing data

• Guide the AA in setting up privacy-friendly UX such as creating options for citizens to provide active opt-ins, clearly separating between terms and conditions that are compulsory and those that are voluntary, or formulating and displaying meaningful privacy notices.

D.2.5 Stage 4 - UAT and Go-Live

D.2.5.1 What happens in Stage 4?

• UAT Sign-off & Go Live permitted for Pilot ULBs or other mandated govt bodies for delivery of services

• Setup of review & monitoring cadence.

D.2.5.2 Owner’s Role in Stage 4

• Guide and review solution implementation, communication/branding, training/adoption.

D.2.5.3. To-Dos

Operational:

• Assist the AA and IA in conducting training of personnel on DPP practices. Sessions can be held on use cases such as:

  • paper-based data management

  • maintaining DPP for paper-to-digital migration

  • identifying PII and classifying it,

  • creating a data usage policy,

  • monitoring access to sensitive data,

  • implementing encryption for data in transit and at rest,

  • regularly testing security measures,

  • providing general training and awareness around data protection,

  • using multi-factor authentication,

  • ensuring secure disposal of confidential information,

  • updating security policies on a regular basis

• Check for any practices for DPP that are missed out or are not completely implemented into the designs

• Set up a check for DPP compliance within the program review process

• Assist the AA and IA in working on any issues or problems that arose from the UAT testing on DPP

D.2.6 Stage 5 - Statewide / ULB-wide Rollout

D.2.6.1 What happens at Stage 5?

-Statewide Rollout in batches

- Help desk effectiveness assured

- Critical bugs fixed

- Program success metrics tracking kick-started

D.2.6.2 What does the platform owner do at stage 5?

• Guide and review in change management, incident management, adoption and awareness plans

D.2.6.3 To-Do’s:

Operational:

• Establish clear procedure, based on MOU and in compliance with existing legal requirements, to ensure that in case any data is shared with the platform owner (e.g. for support or bug-fixing purposes): - A secure channel is used for sharing this data - The data is shared by a person who has the authority to share it - The AA has given authorisation to the platform owner to receive it - No other/unauthorised person receives or accesses this data - Data is not retained after the purpose for its sharing has been completed/achieved

• Assist the AA team and ULB employees in standardizing role creation, logins and access controls in change management

Advisory

• Encourage AA to ensure: - Minimal, purposeful data is collected - Data collected, if sensitive, is encrypted and masked by default - ‘One role, one login’ and such login must not be shared with anyone other than the authorised role - Make citizens aware of the data policy and display it on the UX - Retain data with a documented purpose - Ensure all DPP design features are working and used correctly ( encryption, audit login records)

• Assist the AA team in creating awareness on DPP practices through training workshops and guide the IA in conducting such workshops

• Help the AA maintain and manage any DPP issues or data security issues (assist in incident management).

• Become an advisory point of contact for the AA for any data security or privacy issue.

D.2.7 Stage 6 - Sustenance and Maintenance

D.2.7.1 What happens at Stage 6?

• The first batch of ULBs have been made live after the Pilot.

• There is the adoption of the platform in the program’s jurisdictional zone and amongst its ULB employees and citizens.

D.2.7.2 What does the platform owner do at Stage 6?

• Support and guidance in continued adoption

• Ad-hoc assistance is required in troubleshooting problems

D.2.7.3 To Do’s

Operational

• Assist if there is any issue or doubt that arises in data management, access controls, or security of the platform

• If permitted, regularly scan for vulnerabilities and patch systems and applications to minimize the risk of a breach

Advisory

• Guides AA and IA in better data confidentiality and privacy management.

• If AA and IA insist, take part in leading training programs for employees on best data practices.

Scope

DIGIT, an open-source platform, enables governments and service providers to provide interdepartmental coordination and citizen-facing service delivery systems - currently, in urban governance, sanitation, health, and public finance management.

As citizen data is collected and used for such governance services, data privacy and protection measures are required to ensure this data is managed responsibly and safely.

This document is created to be an online guide, providing guidelines for administrative authorities (government entities like state government bodies, local governing bodies etc.) to maintain data privacy and protect individuals’ data.

• Readers can use this to identify the steps they must take, in their capacity as administrative authorities, to ensure data privacy and protection in the context of a DIGIT or DIGIT-like implementation.

• It can also provide source material for privacy policies, which should be included in each portal & application.

• This is not a technical reference or documentation. It serves as a policy guideline.

References made to DIGIT are also applicable to other platforms similar to DIGIT. Not all parts of the guidelines or featured content may match the reader's platform or context, hence this document is open to be referred to in parts as needed.

Guidelines

These guidelines are to be read through the eyes of roles that are part of the administrative authority’s (AA) offices in the journey of adopting a DIGIT-based system or platforms similar to DIGIT in a government entity/ies.

If a government authority adopts DIGIT as a citizen service platform, then these guidelines are apt. Some points in the guidelines may not be relevant to platforms other than DIGIT in the governance ecosystem. Hence these guidelines have to be read as advisory.

Common roles of government entities that are part of the DIGIT currently are:

• Field level employee

• Line Management employee

• Administrative Officer (AO)

• Domain-level data collector

• Verifiers

• Field inspectors

• State or ULB-level head role/authority

• State administrators

This is a non-exhaustive list of roles.

There may in the future be more roles involved from a government entity while using DIGIT, including Ward-level volunteers and/or Intermediaries

Guidelines to be read with the Digital Personal Data Protection Act, 2023

As the AA adopts platforms like DIGIT, it gets access to digital personal data and therefore comes into the ambit of the Digital Personal Data Protection Act, 2023 (DPDP Act). The roles a Prog plays as per the DPDP Act, can be of a data fiduciary and/or of a data processor. The AA decides the purposes and means of processing the digital personal data-making it a data fiduciary under the Acr. Therefore obligations for data fiduciaries have to be considered for an AA to remain compliant with the DPDP Act,2023.

For these guidelines, we assume that the AA processes or directs the processing of digital personal data to provide for certain benefits, services, certificates, licenses or permits ( these cover most of the functions that DIGIT provides and are mandates of Urban Local Bodies )

It is to be noted that similar guidelines can be found for ‘data controllers’ under the European General Data Protection Regulation (GDPR). There are a few basic and minimum requirements that data controllers (bodies that decide the purpose for processing data and the means used to process the data) have to comply with to ensure data protection by default (DbD and PbD) and design (data minimization, implementing safeguards for protection of data, controlled access to data, limited purposeful storage, etc). In Europe, government entities are legally obligated to maintain DbD and PbD or else they are heavily penalised.

B.1 Guidelines For All Roles

There are a few common guidelines that all roles must follow.

Data security measures and practices stand out as the core / foundational guidelines to follow for all roles.

Data Privacy and Protection (DPP) is only possible when the systems and computer resources receiving and storing data are secure (safe from any harm). Some key data security measures include:

• Access control: Establish audited and controlled access for personally identifying data, including authentication and authorization mechanisms. Authorize individuals only if they have a legal basis and a legitimate purpose to access the data.

• Encryption: Encrypt PII data both in transit and at rest to protect it from unauthorized access and theft.

• Data backup and disaster recovery: Regularly backing up PII data - including auditing the need for PII - if not required then deleting the PII, and implementing disaster recovery plans to ensure that important data can be recovered in the event of a data loss or breach.

• Network security: Implement firewalls, intrusion detection and prevention systems, and other network security measures to protect against cyber threats.

• Vulnerability management: Regularly scan for vulnerabilities and patch systems and applications to minimize the risk of a breach.

• Employee education: Educate employees/contractors/personnel on the importance of data security and provide training on best practices for protecting PII.

• Physical security: Implement physical security measures, such as access controls and video surveillance, to protect against unauthorized access to data centres and other data facilities.

• Third-party security: Carefully vet third-party vendors and service providers, to ensure that they have appropriate security measures in place to protect PII.

• Incident response: Develop and test incident response plans to ensure that the organization can quickly and effectively respond to a security breach.

• Compliance: Adhere to relevant security and privacy regulations, such as the IT Act, 2000, and its subsequent amendments and Rules. Conforming with standards such as ISO 27001 is also a good practice.

B.2 Detailed Guidelines For Administrative Authority

The broad roles we cover under these guidelines include:

• Administrative authority (AA) - the body mandated to provide for the government service, usually an agency or department of the State government. This can include bodies like the State Program Directorate and Program Monitoring Units. The above-listed roles (In Section D) come under this category.

• Implementation agency - the body that implements the platform provided by the platform owners into the administering authority’s IT systems.

• Maintenance team - can be an additional team that gets involved after the platform is implemented in the administering authority’s systems to maintain the system.

The previous document in this series covered the guidelines for platform owners/providers.

To understand what each role should do to safeguard DPP, it is important to understand what these roles do at each phase of the implementation of DIGIT.

B.2.1. Stage 0 -Program Setup

What is a program?

A program can be a delivery of any government service/s which the AA is mandated to provide to citizens for which it requires a platform. Defining the scope of the program is within the power of an AA.

D.2.1.1 What happens in this stage?

• A Memorandum of Understanding is signed between the AA and the platform owners.

• The AA appoints a State Program Head/Nodal Officer.

• Resources and funding for the program are identified.

• The AA-specific procurement process is defined.

• SI team onboarding is initiated.

D.2.1.2 AA and implementing agency’s role at Stage 0

• Ensure onboarding of manpower and infrastructure as specified.

• Lead the setup of the program and related governance structure

• Appoint program steering committee and state nodal officer.

• Initiate onboarding of implementation partner.

• Initiate onboarding of Cloud infrastructure provider.

• Identify module deployment priorities

B.2.1.3. To-Dos

Operational

Must-haves

• The relevant department of the AA makes a financial commitment towards enabling data privacy, protection, and security in the system. This would solidify the operations of any measures taken for DPP.

• Spells out data use and governance terms and conditions in all agreements with partners, e.g. MoUs and contracts.

• There is a clear definition of who owns data who is responsible for data protection, extent and purpose of data access in MoUs and contracts.

• The AA documents the purposes for data collection, use and disclosure. Such purpose is to be found in a legally backed instrument or documentation (can be a government authority-sanctioned document pointing at a law/ policy that needs such data to be processed for citizen delivery purposes).

• AA ensures that the design of the platform would involve data collection and processing only if there is a defined purpose for such data being processed.

• The selection of a particular technological solution considers the risks inherent to that technology. For instance, the AA questions the risks that the tech system brings to the citizens and employees if used for service delivery. Risk assessment can be done by conducting an anticipated data protection impact assessment (DPIA). The platform owner must be involved in this assessment, as they are probably the best placed to evaluate the technologies that might be used and that might involve a high risk for the rights and freedoms of people, making the DPIA necessary.

• AA creates measures that can be put in place to reduce the anticipated risks deduced from the above, taking into account the state of the current technology and the cost of applying them.

B.2.1.3.2 Role of Implementing Agency (IA)

• The other actors that AAs engage with to provide digital government service delivery are -the Implementation Agencies (IA)

At this stage the AA -

• Defines how the IA must ensure that DPP practices are maintained

• Draft a working agreement which commits the IA to safeguard the data and the right of citizens to data protection and privacy

• A few clauses which the AA could ask the IA to contractual perform are:

  • Maintain transparency in data practices (API-based data received, shared or used should be visible to the AA)

  • Report any data security breach to the AA

  • Audit and create safeguards against non-authorized third-party access to data

  Implement appropriate security controls like encryption at source, masking of data, ABAC logins, and conducting regular security audits and checks.

• Regularly educate its employees on data privacy, data ethics and data privacy.

The IA can preferably:

• In the works with the AA, include at least one person having a working knowledge of data security, privacy, and protection. IA usually have an in-house team for data security and privacy; if there is no such team, the IA may bring a person with relevant skills in for the project. In case the AA has chosen an in-house entity to implement the project rather than an IAI, the project in charge should again ensure that a person with these skills is brought in for the project.

B.2.1.3.3 Role of Cloud Infrastructure Providers

At stage zero, the AA begins to consider which infrastructural systems they would be adopting. Cloud infrastructure providers are usually sourced by the IA or by the AA. Choosing a cloud storage provider with safe data governance practices is important to avoid data breaches.

A few must-haves the AAs must keep in mind before selecting a cloud infrastructure provider are:

• The Cloud provider has to be compliant with the data processor's obligations under the Digital Personal Data Protection Act, 2023 [DPDP (ACT)]

• Maintains and implements data protection policies.

• Encrypts PII with private keys,

• Conduct regular security checks and audits on data security and privacy

• Safeguards data from being shared with unauthorized users

• Maintains transparent data storage and governance models

B.2.2 Stage 1 - Program kickoff

B.2.2.1 What happens at Stage 1-

• Publishing of the program charter and implementation plan.

• Master data collection kickoff in Pilot ULBs

• Cloud Infrastructure is procured

• Program branding is done (name, logo, tagline etc.)

B.2.2.2 AA team + implementing agency (IA) role at Stage 1:

1. Identify Pilot ULBs (urban local bodies) or any other local governmental agency or body that is mandated to provide the government service

2. Appoint the data collection team and initiate data collection from the Pilot ULBs/ bodies in the required format.

3. Organize implementation kick-off workshop with relevant stakeholders of identified Pilot bodies

4. Create the program charter and implementation plan

B.2.2.3 To-Do’s:

Operational:

Musts

• At this stage, a best practice model of master data collection (steps listed below) is designed - for it to be implemented when actual data is collected at the next stage. - Here master data is the primary data needed for module functionality.

• The master data collection model design includes:

• AA collects minimum personal data - they can do so by collecting personal data only once, using federated databases and interoperable systems to avoid re-collection of personal data.

• The categories of datasets the AA entity would most necessarily require to provide a service are defined and fixed. This is done so as to adopt the practice of collecting only data that is necessary for the provision of a service at the next stage.

• Data without any defined use or need is not collected (data minimisation, legitimate purpose).

• Citizens of the ULBs are informed of the purpose of their data being collected.

• Data collected at the next stage is stored safely ( on paper or digitally). If collected on paper then once transmitted into a digital system, it is destroyed from the paper or source device.

• Dashboards displaying the nature of data to be collected and their corresponding purposes and uses are built; (for transparency and awareness of citizens).

• Specific roles are created for building accountability for safe, limited and purposeful data collection.

• The program charter clearly states that the data provider i.e. the citizen is the owner of the data.

• The implementation plan has DPP practices embedded in it. For example in the processes of data migration and data processing, the system does not permit sensitive data to be visible to unauthorized roles, strict logins are maintained, and the implementing partners' employees are trained in safe data handling.

• Proof of consented collection of personal data (past and future)- either maintained by the AA (as a data fiduciary) or maintained by a separate data processor ( any entity that processes personal data for the AA) and given to the AA as and when necessary.

• Proof of source of personal data -(past and presently held data) which is to be processed is sourced from a database, register or book that is maintained by the administering authority

The DPDP Act permits the AA to process or has processed through a processor any personal digital data of citizens for providing a benefit, subsidy, service, certificate, license or permit (in this case any urban local body function such as birth or death certificate, property license, building plan permit etc) subject to the below conditions :

(i) she has previously consented to the processing of her personal data by the Administering authority or any of its instrumentalities for any subsidy, benefit, service, certificate, licence or permit; or

(ii) such personal data is available in digital form in, or in non-digital form and digitised subsequently from any database, register, book or other document which is maintained by the administering authority or any of its instrumentalities and is notified by the Central Government. All of the above must follow standards that the Central Government may set as policies to follow for processing.

Such previously consented evidence for personal data collection must be maintained for compliance.

• Before master data collection (which partly begins in this stage but is majorly conducted at the next stage), AA arranges for staff/employee training in regard to information privacy protection and awareness of relevant policies regarding citizen's privacy protection

• The AA begins to draft a privacy policy, envisioning its data governance model.

• AA ensures that the IA is onboarding a team with appropriate skill sets through reviews and initial expectation-setting

• The implementation kickoff workshops with representatives of the AAs includes training on purposeful master data collection (for the next stage) in an informed and transparent manner (letting the citizen know why they are collecting the data).

• As suggested in the above stage, a secure cloud infrastructure provider is appointed.

B.2.3 Stage 2 - Solution Design

B.2.3.1 What happens in Stage 2

• Standardized ontologies (uniform terminology for easier understanding), processes and workflows are created.

• Master data collected in the desired format.

• Agreement on AA-specific product customisations is required.

• A detailed program plan is made and the tracking mechanism is finalised.

B.2.3.2 What do the AA team and IA do in Stage 2

• Standardize the ontology, processes and workflows in the states

• Initiate policy change if required

• Provide state-specific requirements, if any.

• Lead solution design, impact analysis, and integration analysis.

• Get designs and requirements signed off.

B.2.3.3 To-Dos

Operational

Musts

• AA conducts assessments on data governance of the prepared processes and workflows before finalisation. This includes factors like:

• Personally identifying information (PII) to be used in an encrypted/ masked manner through the workflows.

• Processing of data takes place only if the benefits from the use of the processed data would be proportional to the risks that such processing produces.

• Data that flows in the processes and workflows have strict access requirements

• As per the DPDP Act, citizens would have a right to access on request -

(a) a summary of personal data that is being processed by the AA and the processing activities undertaken by that AA with respect to such personal data; (b) the identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared by the AA, along with a description of the personal data so shared; and (c) any other information related to the personal data of such Data Principal and its processing, as may be prescribed.

As per this right, the AA must maintain a record of the personal datasets it has captured

• The above Act also empowers citizens with a right to correct, completely update and erase data. The AA must, on receiving the request of the citizen, correct the inaccurate or misleading data, complete the incomplete data, update the personal data, and also erase the data unless a specific purpose or legal compliance requires such data to remain.

As per the above, the AA has to create processes to undertake such correction, completion, erasure or updation of data - for which keeping an audit log of what data is collected, why, for how long and where is crucial.

• At this stage, the AA initiates the introduction of a state-level data policy for clear, legitimate and informed data governance practices it plans on adopting.

• Product customization requested by the AA keeps in mind the breach of data and confidentiality and the rights of citizens to data privacy. The AA studies the risks and harms that customisation would cost to the safety of the citizen through the use of his/her data (proportionality test). The risks, harms and benefits assessment will take into consideration the impact that data use may have on an individual(s) and/or group(s) of individuals, whether legally visible or not and whether known or unknown at the time of data use.

• Configurations include the feature of asking for feedback from citizens when the platform proceeds for a UAT. Citizens are asked for feedback on how data is being handled and whether they are aware of why their data is being used.

• Service Level Agreements include security checks at each level of implementation of the platform for data to be kept secure and safe.

Technical

• AA implements privacy-enhancing technologies (PeTs), such as encryption, anonymization, and access control systems, to protect the personal data that is part of the master data.

• The existence, nature, and anticipated period of retention of data and the purpose of data used through the workflows and processes are publicly disclosed and described in clear and non-technical language suitable for a general audience

B.2.4 Stage 3 - Customisations & Configuration

B.2.4.1 What happens in this stage

• A configured/customized product is created that is ready for UAT (User acceptance testing).

• Monitoring Reports and Dashboards are ready ( to understand the rollout of the modules).

• Product artefacts like user guides are created.

• Identification of participants for the UAT session.

B.2.4.2 What does the AA team do in Stage 3

• Master data cleaning and validation.

• Collect ULB-specific baseline data to measure performance and adoption.

• Identify ULB level Nodal officers for day-to-day support.

B.2.4.3 To-Dos

Operational

Musts

• At this stage, the user guides, and instruction manuals are created which include guidelines and best practices on DPP. These user guides could pick up practices from Table 2 here.

• The master data cleaning and validation is the last opportunity for the AA officials to decide on the necessity of data collected for defined purposes. If no corresponding purpose is found for a dataset collected, the dataset does not proceed to flow through the UAT demo.

• The nodal officers are made aware (through training and workshops) of the importance of data privacy and protection and are trained to manage data in a secure manner

• The AA’s privacy policy is visible on the UX ( privacy policy must be easy to understand and small - a sample privacy policy can be found here)

• AA assesses the design of dashboards displaying data, and other data interactions, just as one would for other elements of the product experience.

• AA conducts reviews and checks on whether people can easily access and understand relevant privacy information, whether participants feel they have the right information at the right time, and whether they are in the appropriate state of mind to take informed action.

• As part of UAT, include questions that check if the platform permits people to access their data, understand the purpose for such data being used, by whom is it used and what happens to the data after its use is over. AAs or IAs can use this sheet as an activity to assess if they are providing the rights to citizens.

B.2.5 Stage 4 - UAT & Go-Live

B.2.5.1 What happens in Stage 4

• UAT Sign-off & Go Live permitted for Pilot ULBs or other mandated govt bodies for delivery of services

• Setup of review & monitoring cadence.

B.2.5.2 What do the AA team and IAs do in Stage 4

• Conduct user acceptance testing and provide sign-off.

• Organise ULB employee training workshops.

• Set up help desks and support mechanisms for ULB.

• Lead the UAT / pilot / Go-live as required along with training key client personnel.

B.2.5.3. To-Dos

Operational

Musts

• Ensure that the training program for the AA personnel includes DPP practices training as well (can include training in data ethical data collection, use and storage, communicating purpose of data collection, etc.)

• Conduct a data security check while/before conducting the UAT (A data security checklist should include questions like-

• Is PII data encrypted when shared?

• Is data stored in safe databases?

• Do limited roles have access to PII?

• Are employees aware of incident reporting?

• Is there a data protection and privacy policy for hardware protection and external media devices? (Wherever there is a use of removable physical media document the use of such removable physical media and maintain an accurate, up-to-date record of the user profiles created for users who have been authorised access to the information system and the personal data contained therein).

• As part of the review and monitoring cadence the AA creates a DPP checklist (A DPP checklist can have items like -

• A privacy policy has been established and approved by the AA

• PIAs, or privacy risk assessments, are planned to be regularly performed

• Data processing agreements have been established with all third parties that will process personal data

• The software and infrastructure regularly undergo security risk and threat analysis

• AA has a privacy education/awareness training program

• AA is prepared to handle security incidents affecting personal data

• The amounts of personal data that can be collected have been minimized

• The purpose of data collection has been defined to be as specific as possible

• Any sharing of personal data to third parties has been clearly specified

• The retention date is no longer than necessary to fulfil the purpose of data collection (or to comply with existing legislation)

• The privacy policy clearly states who are responsible for the personal data and how they can be contacted

• The privacy policy is clearly written, to make it easy to understand the intended end-users

• The length of the privacy policy is not excessive

• The privacy policy can easily be retrieved by citizens at all times

• The helpdesks provide simple material to explain to citizens or employees the concepts of DPP. These help desks serve as one-stop spots for citizens and employees to understand DPP concepts like data privacy methods, masking and limited and purposeful data sharing. Therefore the help-desk representatives are trained well in DPP concepts and use cases before the platform goes live. They also become the first stop for any incident to be reported on data privacy breach

B.2.6 Stage 5 - Statewide/ULB-wide Rollout

B.2.6.1 What happens in Stage 5

-Statewide Rollout in batches

- Help desk effectiveness assured

- Critical bugs fixed

- Program success metrics tracking kick-started

B.2.6.2 What do the AA team and IAs do in Stage 5

• Lead rollout, training, change management workshops, training activities and monitoring with client teams.

• Plan phase-wise pan-state rollout.

B.2.6.3 To-Dos

Operational

• There is transparency on measures taken for protecting citizens' data privacy and protection ( dashboards showing steps taken, open display of categories of data the AA can see and use, grievance redressal officer appointed)

• Awareness has been built amongst AA team/departments and ULB employees on DPP practices listed above and now employees are held accountable for displaying their training in their functions.

• Regular Privacy Impact assessments (including gap assessments) and data security audits are conducted to check whether the state-wide platform is safeguarding DPP. Refer to Table 2 to understand if the AA has considered global practices and principles of data protection and privacy for adoption.

• Feedback loops must remain active and are speedy at providing solutions for any anticipated or addressed privacy or data protection issue that comes up

• While transitioning from old/existing systems to new platform-based systems, the data migration process has taken into consideration data masking, encryption, data deletion, purposeful data retention, etc.

B.2.7. Stage 6- Sustenance & Ongoing Improvement

B.2.7.1. What happens in Stage 6

• The first batch of ULBs has been made Live after the Pilot.

• There is the adoption of the platform in the State among the ULB employees and the citizens.

B.2.7.2 What does the AA or IA team do in this Stage

• The adoption tracking & review cadence is set up.

• The adoption team at the State and ULB level are set up to drive the adoption of the system.

• The state runs multi-channel awareness campaigns to drive adoption among the citizens of the state.

B.2.7.3 Role of Supporting Agency

• At this stage, a Supporting agency’ (SA) gets involved. An SA is one that provides support in any functional aspect required by the Prog with respect to that platform implementation (e.g. assistance in maintenance of the platform, technical or operational problem-solving, bug/error resolution).

• An SA can be contracted at Stage 5 or at this stage.

• It primarily assists, guides, firefights and resolves difficult problems for the AA while the platform is implemented/ getting implemented.

• An SA can be given a specific role of overseeing and helping in the DPP practices adoption.

B.2.7.4 To-Dos

Operational

Musts

• The AA team conducts reviews on the comfort or discomfort citizens are experiencing with the above DPP practices and design features implemented on the ground.

• Feedback is received from the citizens. Such feedback is analyzed and relevant AA officials are alerted about such feedback for steps to be taken for improvement.

• An SA oversees the applicability of the DPP features are live and troubleshoots any problems arising for all stakeholders.

• SA whose duty is to set DPP practices into action must create impact reports, firefight any issues that arise and create operational awareness for all stakeholders within the AA.

• Awareness campaigns are conducted to build awareness of citizens on their right to data protection and privacy.

• There are continuous sessions for employees of AA and IA held on DPP training.

• AA or implementation team holds community or ULB-based workshops and creates awareness materials like posters, videos, brochures etc.

B.2.8 Preferable Practices As Guidelines

There are a few guidelines that are preferred to be followed by the AA but are not to be taken as a must-do. A few of them are:

Stage 1: Program Kick-off

Preferable:

• The data collection model is designed to collect the consent of the citizen before collecting the data. Such consent is recorded in a log registry and maintained with each AA department.

• There are privacy-specific KPIs or OKRs (objectives and key results) embedded. For example - setting privacy benchmark deliverables like privacy audits and security gap assessments. This would help the AA and IA monitor privacy issues and provide early warning of problems.

• AA provides procedures for citizens to complain or inquire about their data

Stage 2: Solution design

Preferable:

• AA and IA use privacy concepts as a prompt for generating ideas, such as a ‘crazy eights’ sketching exercise that explores how the platform might work if it processes no personal information (to reduce the amount of PII collected)

• AA establishes an internal system for constant data updation and deletion of obsolete data, wherever appropriate and practically possible ( to maintain data accuracy and quality).

Scope

DIGIT, an open-source platform, enables governments and service providers to provide interdepartmental coordination and citizen-facing service delivery systems - currently, in urban governance, sanitation, health, and public finance management.

As citizen data is collected and used for such governance services, data privacy and protection measures are required to ensure this data is managed responsibly and safely.

This document is created to be an online guide, providing guidelines for Program owners to maintain data privacy and protect individuals’ data.

• Readers can use this to identify the steps they must take, in their capacity as program owners, to ensure data privacy and protection in the context of a DIGIT or DIGIT-like implementation.

• It can also provide source material for privacy policies, which should be included in each portal & application.

• This is not a technical reference or documentation. It serves as a policy guideline.

References made to DIGIT are also applicable to other platforms similar to DIGIT. Not all parts of the guidelines or featured content may match the reader's platform or context, hence this document is open to be referred to in parts as needed.

These guidelines are to be read through the eyes of roles that are part of the program owners' (Prog) offices in the journey of adopting a DIGIT-based system or platforms similar to DIGIT in a government entity/ies.

If a government authority adopts DIGIT as a citizen service platform, then these guidelines are apt. Some points in the guidelines may not be relevant to platforms other than DIGIT in the governance ecosystem. Hence these guidelines have to be read as advisory.

The previous document in this series covered the guidelines for platform owners (PO), implementing agencies (IA) and administering authorities (AA).

These guidelines share great similarities with the ones created for the AA.

For this document to understand what each program owner should do to safeguard data privacy and protection (DPP), it is important to understand what a Prog does at each phase of the implementation of DIGIT.

Guidelines to be read with the Digital Personal Data Protection Act, 2023

As the Prog adopts DIGIT, it gets access to digital personal data and therefore comes into the ambit of the Digital Personal Data Protection Act, 2023 (DPDP Act). The roles a Prog plays as per the DPDP Act, can be of a data fiduciary and/or of a data processor. Depending on the nature of control the Prog has over deciding the purpose and means of data processing shall make it either a data fiduciary or no such control shall make it a data processor. Therefore obligations for both the roles have to be considered for a Prog to remain compliant with the DPDP Act,2023.

For these guidelines, we assume that the Prog processes digital personal data to provide for certain benefits, services, certificates, licenses or permits ( these cover most of the functions that DIGIT provides and are mandates of Urban Local Bodies).

Program Stages

B.1 Stage 0 -Program Setup

What is a program?

A program can be a delivery of any government service/s which the AA is mandated to provide to citizens for which it requires a platform. Defining the scope of the program is within the power of an AA.

B.1.1 What happens in this stage

• A Memorandum of Understanding is signed between the AA and the platform owners. A Prog can also be a party to the MoU or maybe an equal power holding or subordinate entity of the AA (which signs the MOU).

• The Prog appoints a State Program Head/Nodal Officer.

• Resources and funding for the program are identified.

• The Prog-specific procurement process is defined.

• IA team onboarding is initiated.

B.1.2 Program Owner role at Stage 0:

• Ensure onboarding of manpower and infrastructure as specified.

• Lead the setup of the program and related governance structure

• Appoint the program steering committee and nodal officers.

• Initiate the onboarding of the implementation partner.

• Initiate the onboarding of cloud infrastructure providers.

• Guide, support or enable the identification of module deployment priorities

B.1.3 To-Dos

Must-haves:

• Must fold in clauses and language in the MoU or data access/sharing agreement around:

• Data confidentiality and privacy breach provisions with consequences (as prescribed under Sec 72 of the Information Technology Act, 2000)

• For strict access controls, damage accountability, and consequences for any data privacy and security breach (as prescribed under Sec 43A IT Act, 2000)

Preferable practices:

Actions which the Prog should ensure are required of the IA (i.e. included as responsibilities of the IA in the contract) are:

• Maintain transparency in data practices and mandate regular reporting

• Create safeguards against non-authorized third-party access to data

• Implement appropriate security controls like encryption at source, masking of data, RBAC logins, and conducting regular security audits and checks.

• Conduct periodic audits of access

• Report any data security breach to the Prog

• Regularly educate the employees of the Prog on data privacy, data ethics and data privacy.

• Conduct a risk assessment of the platform technology along with regular data protection impact assessment (DPIA). It is important that the platform owner is involved in this assessment, as they are probably the best placed to evaluate the technologies that might be used and that might involve a high risk for the rights and freedoms of people, making the DPIA necessary.

• The cloud infrastructure provider should be selected on the grounds that it:

- Maintains and implements data protection policies.

- Encrypts PII with private keys,

- Conduct regular security checks and audits on data security and privacy

- Safeguards data from being shared with unauthorized users

- Maintains transparent data storage and governance models

B.2. Stage 1 - Program Kickoff

B.2.1 What happens in Stage 1

• Publishing of the program charter and implementation plan.

• Master data collection kickoff in Pilot ULBs (Urban Local Body).

• Cloud Infrastructure is procured.

• Program branding is done (name, logo, tagline etc.).

B.2.2 What does the Prog’s team do in Stage 1

• Appoint the data collection team and initiate data collection from the Pilot ULBs/ bodies in the required format.

• Be a part of the implementation kick-off workshop or help organize it to include relevant stakeholders

• Assist in creating the program charter and implementation plan

B.2.3 To-Dos

Must-haves:

• Proof of consented collecting of personal data (past and future)

• Proof of source - presently held personal data and any past personal data which is to be processed is sourced from a database, register or book that is maintained by the administering authority

The DPDP Act permits the Prog to process any personal digital data of citizens for providing a benefit, subsidy, service, certificate, license or permit ( in this case any urban local body function such as birth or death certificate, property license, building plan permit etc) subject to the below conditions :

(i) she has previously consented to the processing of her personal data by the Administering authority or any of its instrumentalities for any subsidy, benefit, service, certificate, licence or permit; or (ii) such personal data is available in digital form in, or in non-digital form and digitised subsequently from any database, register, book or other document which is maintained by the administering authority or any of its instrumentalities and is notified by the Central Government. All of the above must follow standards that the Central Government may set as policies to follow for processing.

Such previously consented evidence for personal data collection must be maintained for compliance.

• Include in the program charter:

• That the data provider i.e. the resident is the owner of the data.

• Include the duty of maintaining data privacy and confidentiality of data collected in the program charter to avoid any illegal breach

• Include in the implementation plan

• Access controls and data collection practices to avoid breach of privacy or confidentiality of data

• Consequences for third party unauthorized access to data

• Safeguard measures to avoid any breach of law

• Training of data collection teams in topics of safe data access, collection and storage

• Safe and audited data sharing and transfer channels of data

• Cloud infrastructure to have sufficient data safety and security features. It must have privacy by design inbuilt into its infrastructural design (encrypted storage, tight access controls, strict data security).

Preferable/Good practices:

At this stage, a best practice model of master data collection (steps listed below) can be designed (Here, master data is the primary data needed for module functionality).

The master data collection model design includes:

• Collecting data only if it is needed for a specific legitimate reason and defined purpose (data minimisation, legitimate purpose).

• Informing residents about the legal basis and reason/purpose for their data being collected (when collected directly from the resident).

• Data encryption and masking when data is being migrated from paper to digital or old or new digital systems.

• Strategies for safe storage of data ( on paper or digitally).

• Destroying paper-based data after a defined migration period (AA or Prog to define a data deletion period post-migration).

• Maintaining dashboards that display the nature of data to be collected and their corresponding purposes and uses (for transparency and awareness of citizens).

• Embedding DPP practices in the implementation plan. For example, in the processes of data migration and data processing, the system does not permit sensitive data to be visible to unauthorized roles, strict logins are maintained, and IA employees are trained in safe data handling.

• Draft/adopt a data privacy policy.

• Ensure, through scope setting and reviews, that the IA is onboarding a team with appropriate Data privacy and protection safeguarding skill sets

• The implementation kickoff workshops include training on purposeful master data collection (for the next stage) in an informed and transparent manner (letting the residents know why they are collecting the data).

B.3 Stage 2 - Solution Design

B.3.1 What happens in Stage 2

• Standardized ontologies (uniform terminology for easier understanding), processes and workflows are created.

• Master data collected in the desired format.

• Agreement on program-specific product customisations is required.

• A detailed program plan is made and the tracking mechanism is finalised.

B.3.2 What does the Prog team do in Stage 2

• Approve standardized ontologies, processes and workflows.

• Implement the policies required for work to begin on implementation.

• Enable and support the IA in solution design, impact analysis, and integration analysis.

• Signs off on design and requirements.

B.3.3 To-Dos

Must-haves:

Check for factors like:

• Data that includes personally identifying information (PII) is kept in an encrypted/ masked manner through the workflows.

• Strict data access requirements are in place (audit logs, restricted access points)

• Data policy is created to ensure compliance with the law for data protection against breaches of confidentiality and privacy.

• Avoid customisation, workflows, processing etc. that will cause unauthorized access to PII.

As per the DPDP Act, citizens would have a right to access on request -

(a) a summary of personal data that is being processed by the AA or the Prog and the processing activities undertaken by that Prog with respect to such personal data; (b) the identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared by the Prog, along with a description of the personal data so shared; and (c) any other information related to the personal data of such Data Principal and its processing, as may be prescribed.

As per this right, the AA must maintain a record of the personal datasets it has captured.

• The above Act also empowers citizens with a right to correct, completely update and erase data. The AA must, on receiving the request of the citizen, correct the inaccurate or misleading data, complete the incomplete data, update the personal data, and also erase the data unless a specific purpose or legal compliance requires such data to remain.

As per the above, the AA has to create processes to undertake such correction, completion, erasure or updation of data - for which keeping an audit log of what data is collected, why, for how long and where is crucial.

Preferable/Good practices:

• Conduct a risk assessment of the customizations checking for risks and harms leading to breach of confidentiality or data privacy. The assessment will take into consideration the impact that data use may have on an individual(s) and/or group(s) of individuals, whether known or unknown at the time of data use.

• Push for configurations to include the feature of asking for feedback from citizens when the platform proceeds for a UAT. Citizens are asked for feedback on how data is being handled and whether they are aware of why their data is being used.

• Ensure that service level agreements include security checks at each level of implementation of the platform for data to be kept secure and safe.

• Define a data retention period, keeping in mind purpose and legal requirements.

B.4 Stage 3 - Customization & Configuration

B.4.1 What happens in this stage?

• A configured/customized product is created that is ready for UAT.

• Monitoring Reports and Dashboards are ready (to understand the rollout of modules).

• Product artefacts like user guides are created.

• Identification of participants for the UAT session.

B.4.2 What does the Prog do in Stage 3?

• Supervises the master data cleaning and validation.

• Enables collection of ULB-specific baseline data to measure performance and adoption.

• Identifies ULB-level Nodal officers for regular support.

B.4.3 To-Dos

Must-haves:

• All data-related processes at this stage are undertaken while maintaining the confidentiality of the data (masking, restricted access, role-based access control).

• Testing data should not include PII.

• User guides have clear steps on data access and sensitive data management.

• The consequences of unauthorized access and breach of privacy and confidentiality are made clear to all team members.

• Any customization or configuration that could lead to a breach of data and affect the data privacy of citizens is rejected.

• Ensure that the privacy policy is visible on the UX (privacy policy must be easy to understand and small - a sample privacy policy can be found here).

Preferable/ Good practices:

• Ensure that the nodal officers are made aware (through training and workshops) of the importance of data privacy and protection, and trained to manage data securely

• Check for feedback from employees on access mechanisms and delivering services with proposed levels of data access, masking, etc (Can use this sheet as an activity to assess how they are ensuring the privacy rights of residents).

B.5 Stage 4 - UAT & Go-Live

B.5.1 What happens in Stage 4?

• The User acceptance test is conducted and a sign-off and go-live permission is given for identified Pilot ULBs or other mandated govt bodies for the delivery of services.

• Setup of review & monitoring cadence.

B.5.2 What does the Prog team do in Stage 4?

• Enables or conducts user acceptance testing

• Organizes ULB employee training workshops

• Sets up help desks and support mechanism for ULB’s

• Lead the UAT / pilot / Go-live as required along with training key client personnel

B.5.3. To-Dos

Must-haves:

• Training of employees on data safety and privacy practices

• Conduct data security checks before signing off on the UAT.

A data security checklist should include-

• Personally identifying information (PII) data is encrypted/masked when shared

• Data is stored in safe databases

• Employees don’t openly share access logins

• Limited roles have access to PII,

• Employees trained in incident reporting,

• Data protection policy for hardware protection, external media devices

• The monitoring and evaluation cadence has data privacy and protection as a threshold for security checks. A report is submitted to Prog as part of the review and monitoring cadence for DPP:

• The privacy policy is uploaded and displayed

• The privacy policy clearly states who is responsible for the personal data and how that official can be contacted

• Assessments for data breaches and security checks are planned to be regularly performed

• Data processing and sharing agreements have been established with all third parties that will process personal data

• The software and infrastructure regularly undergo security risk and threat analysis

• The program has a privacy education/awareness training

• SOP for security incidents affecting personal data is established

• The amounts of personal data that can be collected have been minimized

• The purpose of data collection has been defined to be as specific as possible

• The data is retained only till there is a need for it

• There are checks on data sharing, with verification that sharing is legally authorised and approved by the appropriate official

Preferable practices:

• The help desks provide simple material to explain to citizens or employees the concepts of DPP. These help desks serve as one-stop spots for citizens and employees to understand DPP concepts like data privacy methods, masking, and limited and purposeful data sharing. Therefore the help-desk representative is trained well in DPP concepts and use cases before the platform goes live. They also become the first stop for any incident to be reported on data privacy breach.

B.6 Stage 5 - Statewide / ULB-wide Rollout

B.6.1 What happens in Stage 5?

• Statewide Rollout in batches

• Help desk effectiveness assured

• Critical bugs fixed

• Program success metrics tracking kick-started

B.6.2 What does the Prog do in Stage 5?

• Leads the rollout, training, and change management workshops,

• Monitors training activities

B.6.3 To-Dos

Must-haves:

• Receive regular reports on any data breaches

• Maintain a check on access controls

• Regularly update and train employees on safeguards

Preferable/Good practices:

• Maintain transparent practices for data governance

• Work with employees to apply their DPP training in their functions.

• Receive reports on Privacy Impact assessments (including gap assessments) and data security audits to check whether the program is safeguarding DPP. Refer to Appendix B in this memo to understand if the Prog has considered global practices and principles of data protection and privacy for adoption.

• Maintain active feedback loops to provide solutions for any anticipated privacy or data protection issues that may arise

• Manage data migration processes (while transitioning from old/existing systems to new platform-based systems) to maintain data safety and privacy best practices, i.e. data masking, encryption, data deletion, strict access controls, etc.

B.7. Stage 6- Sustenance & Ongoing Improvement

B.7.1. What happens in Stage 6?

• The first batch of ULBs have been made live after the Pilot.

• There is the adoption of the platform in the program’s jurisdictional zone and amongst its ULB employees and citizens.

B.7.2 What does the Prog do in this stage?

• Maintains the adoption tracking & review cadence.

• Drives the adoption of the system.

• Implements multi-channel awareness campaigns.

B.7.3 To-Dos

Must-haves:

• Prog checks for all of the above data privacy and protection measures being maintained and continuously running

• Prog reviews implementation of DPP practices and reviews issues in adoption by employees. Prog tries to balance service delivery and data privacy and security.

Preferable/Good practices:

• Conduct awareness campaigns for residents on their right to data protection and privacy, and DPP measures being taken in the program.

• Organizes sessions for employees and contractors of Prog (and IA / SA if relevant) on DPP measures, principles, practices, etc.

• Create awareness materials like posters, videos, brochures etc.

Scope

DIGIT, an open-source platform, enables governments and service providers to provide interdepartmental coordination and citizen-facing service delivery systems - currently, in urban governance, sanitation, health, and public finance management.

As citizen data is collected and used for such governance services, data privacy and protection measures are required to ensure this data is managed responsibly and safely.

This document is created to be an online guide, providing guidelines for Implementing agencies to maintain data privacy and protect individuals’ data.

• Readers can use this to identify the steps they must take, in their capacity as implementing agencies, to ensure data privacy and protection in the context of a DIGIT or DIGIT-like implementation.

• It can also provide source material for privacy policies, which should be included in each portal & application.

• This is not a technical reference or documentation. It serves as a policy guideline.

References made to DIGIT are also applicable to other platforms similar to DIGIT. Not all parts of the guidelines or featured content may match the reader's platform or context, hence this document is open to be referred to in parts as needed.

These guidelines are to be read through the eyes of roles that are part of the Implementation Agencies (IA) offices in the journey of adopting a DIGIT-based system or platforms similar to DIGIT in a government entity/ies.

As per the Digital Personal Data Protection Act, 2023 (DPDP Act) an IA would be a data processor. If the IA gets involved in deciding the purpose and means of the data processing, then it would become a data fiduciary. The guidelines below cover measures to be in compliance with the DPDP Act.

If a government authority adopts DIGIT as a citizen service platform, then these guidelines are apt. Some points in the guidelines may not be relevant to platforms other than DIGIT in the governance ecosystem. Hence these guidelines have to be read as advisory.

The previous document in this series covered the guidelines for platform owners (PO), and administering authorities (AA).

For this document to understand what each program owner should do to safeguard data privacy and protection (DPP), it is important to understand what IA does at each phase of the implementation of DIGIT.

Implementation Stages

B.1 Stage 0 - Program Setup

What is a program?

A program can be a delivery of any government service/s which the AA is mandated to provide to citizens for which it requires a platform. Defining the scope of the program is within the power of an AA.

B.1.1 What happens at this stage?

• A Memorandum of Understanding is signed between the AA and the platform owners. A Prog can also be a party to the MoU or maybe an equal power holding or subordinate entity of the AA (which signs the MOU).

• The AA appoints a State Program Head/Nodal Officer

• Resources and funding for the program are identified.

• The program-specific procurement process is defined.

• IA team onboarding is initiated.

B.1.2 IA’s role at Stage 0:

• At this stage, the IA becomes a part of the program.

• An official MoU or contract is entered into detailing the terms and conditions between the IA and the AA or Prog

• IA begins to understand the needs of the program

• IA begins making an implementation plan, that shall be published in the next stage

B.1.3 To-Do’s

Must-haves:

• IA must ensure there is an authorization document/proof/contract (MoU) - validating and authorizing the IA’s access to future data and its related compliances ( in compliance with Sec 8 of the Digital Personal Data Protection Act,2023)

• IA presents its own data management and privacy policy to the AA or Prog. This would make the IA’s stand on DPP very clear and easier for the AA or Prog to design a data sharing/access agreement with the IA

• The clauses and language in the MoU/ data access/sharing agreement with the AA or Prog must include:

• Data will always be controlled by the AA or the Prog, and IA will never have data-controlling power (IA must not decide the purpose and means of the processing of the data)

• IA will be restricted from third-party data sharing without authorization from the AA or Prog

• IA will not collect personal identifying information (PII) from citizens directly or indirectly without written permission by the AA or Prog

• Access to PII by the IA team should be role-based, through strict logins audited and reported to the AA or Prog

• IA will access PII only for purposes specified and authorized by the AA or Prog

• IA will not keep any PII backup or secondary copy of such data

• Data breach consequences - who holds accountability for data breaches

• In the implementation plan, the IA must push for maintaining the data safely and securely from the beginning of the program life cycle to avoid any data or confidential breach. For example - the IA can detail a data-sharing mechanism that masks direct PII from being visible to IA representatives

• The IA should make clear the access, processing and sharing of data in the implementation plan to avoid future confusion on data accountability

• At every step of the implementation plan, the IA must reduce or eliminate its access to PII

• Privacy enhancing features like encryption, privacy by default steps including purposeful processing of data, data deletion post use and strictly restricted access to PII must find a big space in the implementation plan

Preferable practices:

• Assist/advise the AA/Prog in mapping out resources and funding needs for maintaining safe data protection and security structures ( hardware and software)

• Embedding DPP practices in the implementation plan. For example, in the processes of data migration and data processing, the system does not permit sensitive data to be visible to unauthorized roles, strict logins are maintained, and IA employees are trained in safe data handling.

• Help the AA or Prog make a program-specific data privacy policy (if they don’t have one made already for the specific program).

B.2. Stage 1 - Program Kickoff

B.2.1 What happens in Stage 1

• Publishing of the program charter and implementation plan.

• Master data collection begins in Pilot (selected) ULBs (Urban Local Body)

• Cloud Infrastructure is procured

• Program branding is done (name, logo, tagline etc.)

B.2.2 What does the IA team do in Stage 1