Information Confidentiality Classification And Tool Usage
Version | Editor | Changes |
1.3 | Nico Lück | Introduced channel “GovStack Global Operations” |
1.2 | Martha Mundas | Updated (e.g. tools, example cases etc.) |
1.1 | Nico Lück | Reduced examples of “normal” class |
1.0 | Nico Lück, Margus Mägi | Inserted regular revision of document by Governance Committee |
0.8 | Nico Lück, Rachel Lawson, P.S. Ramkumar, Esther Ogunjimi, Moritz Fromageot, Ayush Shukla |
|
Purpose of this document
This document is to guide participants of the GovStack community in finding the appropriate place to store information.
As a community driven by the principle of openness, we aim to make decisions and information as much public as possible.
However, to ensure that we do not risk issues to the project, or the partners supporting the project, we must consider the content/data we are handling and store it in locations that mitigate those risks.
The overall way we work is to:
classify content/data and agree how each classification is handled
place reminders of what classification of content/data is appropriate on each platform, where possible
communicate to all members of the project team which platforms are available for use and what classification of content/data is appropriate in each.
Revise this document (especially the examples given per class) at least once every half a year by the Governance Committee
Personal data
Data relating to people’s must always be handled with the greatest care and always in accordance with the rules given by GDPR.
The GovStack project details these rules in its Privacy Policy and they must always be followed before further considering what information to store where, as described in this document.
Classification of Information
Protection needs of the information consider damage that may occur if confidentiality, integrity or availability is compromised.
The person creating the information is responsible for selecting the appropriate classification.
For this person to select the correct classification, the protection need is described in detailed abstract manner and example cases are given. Reoccurring meetings shall be already categorised so that information coming out of this meeting inherit the respective class.
We also define the tools we use to handle information at each classification. There may be exceptions to these rules, especially at the Public classification. At the Normal / High classifications, usage of a particular tool other than that defined here should be cleared with your partner lead.
Protection Need | Potential damage to GovStack Initiative or partners (Def. See below) | Example cases (incl. Meetings) Initially, it is up to the groups to decide the classification of information not yet listed here. However, in long-term, all groups in the category “normal” should consider to move into “non-classified/public”. | Tools we use in the GovStack project for this purpose |
Non-classified/Public information | No damage expected. | General Overall deployment plan and roadmap Events with GovStack participation Governance Committee Meeting and decision Minutes Information on procurements which are also available in the respective web portals Technical Committee Meeting and decision minutes Working Groups (including Building Blocks but also things like Comms, Community etc) Backlog of work Source Code Specs documents, use case definition by working groups. Including in-development versions. Country Engagement (for comms purposes or digital public goods) ..
| Confluence Public Areas Jira Public Areas Slack Github Gitbook Website Social Media |
Normal | Damage impacts are limited and manageable. | Country Engagement Team Work plan priorities, Activities to be done etc. Playbook development Work on Inception Reports Meeting Minutes Communications Post schedule website Working Group/TC Facilitation Coordination of WG facilitators Defining templates/rules on spec writing Milestone planning
| Confluence Restricted Areas Jira Restricted Areas MS Teams direct Chat Slack channel “Global operations” Sharepoint |
High | The damage effects can be considerable. | Founding partner meeting (closed Strategic Governance meeting) Information to coordinate partners on financial, HR, strategy or donor matters. Personal contractual details Country engagement strategic priorities/constraints Report on planned or active procurements Travel plans in fragile contexts Coordination with local implementers in fragile contexts, e.g. Somalia Contracts of the founding partner with third parties, e.g. EU Partnership Management (Donors) Priorities of partners Country Engagement Status of engagement with new countries to be involved into GovStack Description of the Actions, IDGC Code of Conduct Team Meeting Notes Communications and Events Event photos taken at initiative meetings List of event participants (names etc.)
| GIZ MS Teams Sharepoint (closed GC folder) |
Very High | The damage effects can reach an existentially threatening, catastrophic extent. | Personal information of target group (e.g. political activists) Sensitive personal data sets for testing purposes (e.g. real data from partner systems)
| GovStack does not process this class of information |
Protection needs in detail
“Normal” protection needs category
1. Violation of laws/ regulations/contracts
Violations of regulations and laws with minor consequences
Minor breaches of contract with at most low contractual penalties
2. Impairment of the right to informational self-determination
It is a question of personal data, the processing of which may have adverse effects on the social standing or economic conditions of the person concerned.
3. Impairment of the physical integrity of a person
Impairment does not appear possible.
4. Impairment of the ability to perform tasks
The impairment would be assessed as tolerable by those concerned.
The maximum acceptable downtime is between 24 and 72 hours.
5. Negative internal or external effects
Low and/or only internal impairment of reputation/confidence is to be expected.
6. Financial consequences
The financial loss is acceptable to the organisation.
“High” protection need category
1. Violation of laws/regulations/contracts
Violations of regulations and laws with substantial consequences
Major breaches of contract with high contractual penalties
2. Impairment of the right to informational self-determination
It is a question of personal data, the processing of which may have significant adverse effects on the social standing or economic conditions of the person concerned.
3. Impairment of the physical integrity of a person
Adverse effects on the personal integrity cannot be ruled out completely.
4. Impairment of the ability to perform tasks
The adverse effects would be assessed as intolerable by some of the individuals concerned.
The maximum acceptable down time is between one and 24 hours.
5. Negative internal or external effects
Considerable impairment of reputation/confidence is to be expected.
6. Financial consequences
The financial loss is considerable, but does not threaten the existence of the organisation
“Very high” protection need category
1. Violation of laws/regulations/contracts
Fundamental violation of regulations and laws
Breaches of contract with ruinous damage liabilities
2. Impairment of the right to informational self-determination
Includes personal data, the processing of which entails a danger to life and limb or the personal freedom of the person concerned.
3. Impairment of the physical integrity of a person
Severe adverse effects on the personal integrity are possible.
Danger to life and limb
4. Impairment of the ability to perform tasks
The adverse effects would be assessed as unacceptable by all concerned.
The maximum acceptable downtime is less than one hour.
5. Negative internal or external effects
National adverse effects on the reputation or confidence are possible, which may even threaten its continued existence.
6. Financial consequences
The financial loss threatens the existence of the organisation.
Reclassifying information
Of course, we couldn’t classify information without also recognising that there will be occasions where it needs to be reclassified for a particular purpose.
An example of data needing reclassification might be photos taken at an event. By default, they are treated as “Normal” classification meaning they are only stored on email, MS Teams or the private Confluence. If we want to publish them on the website, we need to reclassify as “Public”.
The method to reclassify information is to agree this reclassification in a committee or working group meeting, record the agreement to reclassify the information in the meeting notes and then move the information where it is needed.
I am submitting this contribution based on my experience both within and outside GovStack, having observed governance challenges in multiple initiatives.
© Ott Sarv / GovConsult Foundation 2025.
Licensed under CC BY-SA 4.0. You may copy, modify, and distribute this work if credit is provided to "GovConsult Foundation," the author "Ott Sarv," and include the Email: Contact[at]govconsult.org | Web: https://govconsult.org | Logo (if requested by the author).
Full License: CC BY-SA 4.0
Original document: https://app.gitbook.com/invite/LCFTGXGCwWOKAnpdV12H/bVhLN6ej47mdc59wYhMi
This is a copy of the original document.
Guidance on Strengthening GovStack’s Confidentiality, Data Governance, and IPR Frameworks
Firstly, I would like to express my gratitude for the effort and thought that has gone into drafting the GovStack Confidentiality and Privacy Policy. It’s clear that a significant amount of work has been invested in creating a structured approach to managing sensitive information within the GovStack project. The classification framework reflects a thoughtful and mature understanding of operational risk and the complexities involved in managing a multistakeholder project. It lays a solid foundation for protecting sensitive information and aligning operational practices with strategic objectives.
That said, as GovStack continues to grow and evolve, there are some structural gaps that need to be addressed — particularly in the areas of intellectual property rights (IPR) and data protection under GDPR. These gaps create potential legal and financial risks that could lead to significant exposure for GovStack’s stakeholders — including financial penalties, reputational damage, and legal disputes. I hope the following reflections are helpful in identifying areas where adjustments could strengthen both the internal governance structure and the external legal alignment of the project. My goal is to provide constructive input that supports GovStack’s long-term success while respecting the complexity of its multistakeholder model.
One of the fundamental challenges GovStack faces is that it is a project, not a legal entity. This creates ambiguity over key issues like ownership of intellectual property (IP), data processing responsibility, and liability. Without legal personality, GovStack cannot directly hold intellectual property or serve as a data controller under GDPR. This distinction is important because it means that the legal responsibility for data protection and IP ownership falls back on the contributing and managing partners — primarily GIZ, ESTDEV, and other participating organisations like GovConsult Foundation (GCF). However, the current policy does not make this distinction clear, which creates uncertainty about who is ultimately responsible for certain decisions and outcomes.
The absence of a clear intellectual property rights (IPR) framework is one of the most pressing issues. Since GovStack is a collaborative project, work created within the project — such as working documents, technical specifications, architectural frameworks, and research outputs — would naturally be owned by the contributing party unless there is a formal mechanism for transferring or sharing those rights. Currently, no such framework exists. This means that if GCF develops a specification or if ESTDEV creates a governance framework, the IP would remain with the creator unless a transfer or licensing agreement is in place. The lack of a joint IPR framework creates significant legal and operational ambiguity over ownership, modification rights, and publication.
This issue becomes more complex when considering joint contributions. Many GovStack outputs are not created by a single party — they are the result of collaborative input from multiple stakeholders. For example, a technical specification for a building block might be drafted by GCF, revised by GIZ, and reviewed by ESTDEV. In such cases, it’s unclear who holds the final IP rights or how joint ownership would be assigned. This creates a potential conflict if one party seeks to publish or modify the work without the consent of the other contributors. The absence of a joint IPR framework also creates legal exposure if the work is challenged or misused externally.
The current confidentiality framework complicates this further by allowing for reclassification of data from "High" or "Very High" to "Public." If the underlying work is co-created by multiple stakeholders, reclassification could result in the unauthorised public release of material that is still subject to joint ownership rights. For example, if GCF and ESTDEV jointly create a technical roadmap classified as "High," and GIZ decides to reclassify it as "Public," this could amount to an unauthorised release of protected IP. Without a formal IPR framework, the contributing parties would have limited legal recourse to challenge such a decision.
Moreover, there is no defined mechanism for transferring ownership or licensing rights from contributors to the broader GovStack project or its stakeholders. Since GovStack is not a legal entity, it cannot own IP directly — but a formal licensing or assignment mechanism could allow the project to benefit from partner contributions while respecting the original creators' rights. For example, GCF could develop a technical specification and assign the rights to ESTDEV or GIZ under a limited-use license or open source. This would allow GovStack partners (organizations and individuals) to use and modify the specification while ensuring that GCF retains underlying ownership. A licensing or assignment framework would also protect the project from future conflicts over ownership and modification rights. If GovStack’s outputs were open-sourced under an agreed licensing model, it would provide greater clarity on how the work can be reused and adapted while preserving the original contributors’ rights.
An IPR framework should also define how modifications to jointly created outputs are handled. If ESTDEV makes substantial changes to a technical specification originally developed by GCF, the framework should define whether the modified version remains under joint ownership or whether the changes constitute a separate work with distinct ownership rights. The same principle applies to derivative works — if GovStack partners create a new product or service based on existing specifications, the framework should clarify whether the new work inherits the licensing terms of the original or whether new ownership rules apply.
Without a proper IPR framework and data governance structure, the risk to GovStack’s stakeholders extends beyond operational issues — it carries direct financial and legal exposure. If IP ownership is not properly assigned and protected, several legal and financial risks arise. If GovStack stakeholders publish or modify work without the consent of the original creator, the creator could initiate legal action. Legal disputes over IP ownership can result in costly litigation, financial damages, and reputational harm. A single IP infringement case could result in penalties ranging from €100,000 to €500,000 depending on the nature and value of the work. If multiple stakeholders claim ownership over a GovStack output and there is no joint IPR agreement in place, conflicts over publication, modification rights, and licensing could lead to project delays and legal costs. Settling such disputes through arbitration or litigation could cost between €50,000 and €200,000 per case. If GovStack outputs are published without proper licensing terms, stakeholders could lose potential licensing revenue or face competitive disadvantages if the work is misused by external parties.
On the data protection side, the risks are even more severe. GDPR violations carry substantial financial penalties and reputational damage. Under GDPR, fines for data breaches can reach up to €20 million or 4% of global annual turnover — whichever is higher. If Slack or SharePoint suffered a breach involving personal data held under GovStack, the data controller (likely GIZ or ESTDEV) would face direct financial liability. Data subjects affected by a breach could initiate individual or collective legal action. A single breach-related legal case could cost between €50,000 and €250,000 in legal fees and settlements. A major data breach could require GovStack to suspend operations temporarily to investigate and remediate the breach, resulting in lost productivity and increased costs. The financial exposure from GDPR breaches alone is significant enough to justify immediate attention to the gaps in the data governance framework. If personal data held in Slack, SharePoint, or other platforms is compromised, the financial and reputational consequences could materially affect the project’s viability.
There is also an unresolved issue concerning the reference to Digital Impact Alliance (DIAL) in the website’s privacy policy. DIAL was initially part of GovStack, but they are no longer involved in the initiative. Despite this, the GovStack website privacy policy still references DIAL as the data controller and links to their privacy framework. If DIAL is no longer legally involved with GovStack, this creates a legal and operational gap. If GovStack is relying on DIAL’s privacy policy to handle data protection responsibilities, this raises questions about liability and compliance in the event of a data breach. If DIAL is no longer responsible for data handling within GovStack, then the policy needs to be updated to reflect the current data processing structure, with GIZ and ESTDEV taking over responsibility as data controllers. If DIAL remains responsible for certain processing activities, then the terms of that relationship need to be formally documented and disclosed within the privacy policy. This affects only the GovStack website — not the other platforms and tools used for GovStack operations (such as Slack, SharePoint, and GitHub). However, it creates a perception problem and raises questions about data handling transparency if the privacy terms are not updated.
I understand that these are complex issues that require careful coordination between GovStack’s operational and legal teams. However, addressing these gaps now will help GovStack scale more confidently and avoid potential conflicts or compliance failures down the line. If it would be helpful, I would be more than happy to support the process of developing the data governance framework or contributing to the design of the IPR policy. GovStack’s success depends on building a sustainable and legally sound governance model — and I am confident that with some focused adjustments, this can be achieved.
And guys, we should remember that both ESTDEV and GIZ must also fulfill their internal policies. If the legal teams from both organizations become aware of the current situation, I’m not sure they would be comfortable with the existing structure — especially with the unclear data handling roles, the unresolved IPR issues, and the absence of formal liability-sharing mechanisms. The longer this remains unresolved, the greater the risk that internal or external legal challenges will arise.
Thank you again for the time and effort that has gone into this work. Please let me know if I can be of any further assistance — I would be more than happy to help move this forward.
Best regards,
Ott Sarv
GovConsult Foundation
govconsult.org