Frequently asked questions

No. Sovereignty is not autarky and does not require complete independence. Organizations and states always depend on knowledge, suppliers, raw materials and cooperation.

The goal is for dependencies to be visible, manageable and replaceable where necessary. You can outsource work and still maintain control, as long as responsibilities, rights, access, continuity and exit options are properly arranged.

No. No product can guarantee digital sovereignty on its own. Sovereignty arises from the combination of governance, contracts, jurisdiction, architecture, openness, knowledge, management and feasible alternatives.

OpenKAT and OciDeck can provide concrete building blocks: more insight, verifiability, open formats, self-management and less unnecessary dependency. The organization must consciously design and continue to test these options.

Record a baseline measurement and a desired level for each critical system. Then measure concrete properties, such as the share of known chain parties, tested data export, customer-managed keys, supplier-free recovery, open interfaces and the time needed to switch.

Also report remaining dependencies and accepted risks. Progress does not mean that all dependence disappears, but that the organization gains more insight, freedom of choice and demonstrable room for action.

Make demands before the contract is concluded. Ask about jurisdiction, ownership, data locations, subcontractors, remote management, key management, open standards, export formats, audit rights, continuity and termination.

Also record how evidence is provided and how changes are reported. A quality mark or general marketing claim does not replace a verifiable agreement. Use the ECSF objectives and SEAL levels as a common language where appropriate.

No. European data storage is relevant, but does not say everything about jurisdiction, ownership, management, key access, subcontractors and technical dependence.

Therefore, assess the entire structure: which entities provide the service, which rights can be invoked, who can perform management actions, who manages encryption keys and what exit options are available?

Yes. Dependence can affect the availability, integrity and confidentiality of information. Consider failure or termination of a service, unwanted access under a different legal system or changes that the organization cannot control itself.

That is why sovereignty belongs in regulation, organization and technology: the three interrelated parts described in the book as ROT. It is not a separate political issue besides information security.

Not when requirements are aimed at manageable risks and apply equally and verifiably to all providers. Protectionism primarily protects one’s own industry; sovereignty policy protects control, continuity, integrity and confidentiality.

Nationality alone is therefore a weak criterion. Jurisdiction, enforceable agreements, technical insulation, openness and exit options are more substantive.

No. A European name or location is not a complete guarantee. A European supplier can also be taken over, go bankrupt, rely heavily on non-European technology or provide poor contractual guarantees.

Look at controllable structural features: ownership and control, applicable law, management and key access, chain dependencies, open standards and an executable exit plan.

No. Open source provides important rights to study software, modify it and have it maintained by others. It can therefore support transparency, replaceability and knowledge building.

But those rights only have practical value if there is documentation, people, management, financing, secure updates and access to one’s own data. Open source can also depend on one maintainer, a closed cloud service or infrastructure that is difficult to replace.

No. Sovereignty is context dependent. The desired level follows from the criticality of the process, the sensitivity of data, legal requirements, risk appetite and available alternatives.

The highest level for all systems may be unnecessarily expensive or unfeasible. A motivated choice per system is stronger than one general goal without priorities.

Not necessary. Requirements for interoperability, transparency, security and replaceability can actually stimulate innovation because new suppliers can connect more easily and customers become less locked in.

There are real trade-offs around cost, speed and functionality. These must be made explicit. The contrast between ‘innovation or sovereignty’ is too simple; it is about responsible innovation within a chosen risk profile.

Start with insight. Create an overview of critical processes, data, systems, suppliers, subcontractors, management access, applicable jurisdiction and existing exit options.

Then link the most important dependencies to availability, integrity and confidentiality. Only when it is clear what is critical and what it depends on, can you choose an appropriate goal and measures.

The book Sovereignty! How? discusses the historical development, the relationship with information security, the ECSF, the arguments from the debate and a practical growth path for organizations.

The core message is down to earth: sovereignty is not an all-or-nothing concept and not a one-off project. It is the permanent organization of insight, direction and room for action.

The concept took shape in Europe in the late Middle Ages and early modern period. In the sixteenth century, Jean Bodin described a supreme, permanent state power. The Peace of Westphalia of 1648 then strongly linked sovereignty to territorial states and the principle of non-interference.

Later, the legitimacy shifted from monarchs to the people and states began to exercise powers jointly, for example within the European Union. History shows that sovereignty always revolves around the same core question: who ultimately has the final say?

Because sovereignty is not just about probability, but also about impact and ability to act. An event can be unlikely and yet have unacceptable consequences for a critical process.

Moreover, dependency can already have an influence without actually blocking access. The possibility of sanctions, legal orders or termination can change decision-making and negotiating space.

Governments, companies and social organizations have become highly dependent on a small number of suppliers for cloud, office software, communications and AI. At the same time, ownership, legislation, sanctions, takeovers and geopolitical relationships can change.

As a result, formal control can conflict with actual dependence. The urgent question is not only whether a supplier is reliable today, but whether the organization can still act tomorrow if rules, access or interests change.

Distinguish between truly indispensable functions and dependencies that have arisen due to habit, missing knowledge or old choices. Concretely map out connections, data formats, licenses, processes and skills.

Then practice exporting, recovery and alternatives before there is a crisis. An exit plan that has never been tested offers little certainty. Sometimes full migration is not immediately feasible, but open formats, modular architecture and a second implementation route can already improve the position.

Then a phased approach is wise. First determine for which processes the dependency poses the greatest risk and which functions are really needed. Then improve contracts, architecture and portability, and migrate where a suitable alternative is available.

The fact that an alternative is less mature today is an argument about pace and execution, not automatically a reason to ignore the risk. The book therefore discusses a growth path instead of one big transition.

Digital sovereignty is the extent to which a government or organization actually maintains control over its digital functions, data and dependencies. Formal rights and actual options for action count.

Specific questions are: where is the data located, who can access it, what law applies, who manages the keys, can the service continue in the event of a conflict and is switching realistically possible?

The ECSF is a European assessment framework for cloud sovereignty. It helps public organizations to describe sovereignty risks, set requirements for purchasing and compare the current and desired situation.

The framework shifts the conversation from general claims, such as ‘European’ or ‘sovereign’, to testable properties. It looks at jurisdiction, data, operations, chains, technology, security and sustainability, among other things.

Sovereignty is about authority and direction: who has the final say and bears responsibility? Autonomy is about the practical ability to act independently and use alternatives.

An organization may be formally authorized but have little autonomy if it cannot technically switch or if only a supplier can manage the system. Sovereignty without sufficient room for action then largely remains on paper.

Sovereignty is the authority to make binding decisions and to bear responsibility for them. In digital environments, the main question is who ultimately decides on data, infrastructure, technology and access.

It does not mean that an organization has to build or manage everything itself. However, she must be able to make conscious choices, enforce agreements and act when circumstances change. The book Sovereignty! How? This works out as a practical administrative issue.

SEAL levels describe increasing levels of cloud sovereignty. Level 0 is a standard public cloud without additional sovereignty measures; Level 4 stands for a highly sovereign environment with demonstrable autonomy.

The levels are not a grade for a supplier. They help an organization to determine an appropriate current level (IST) and desired level (SOLL) per application. A critical system can therefore be given a higher purpose than a public or easily replaceable service.

Open source can help because an organization can study software, have it checked, adjusted and maintained by another party. Open rights therefore support transparency, replaceability and the development of one’s own knowledge.

Open source is not an automatic guarantee of sovereignty. The practical value also depends on documentation, people, management, financing, secure updates, open data formats and the infrastructure on which the software runs.

The ECSF distinguishes eight interrelated goals: strategic sovereignty; legal and jurisdictional sovereignty; data and AI sovereignty; operational sovereignty; chain sovereignty; technological sovereignty; security and compliance sovereignty; and sustainability sovereignty.

This classification prevents one characteristic, such as the location of a data center, from being wrongly used as evidence for full sovereignty. A service can score strongly on one goal and weak on another.

OciDeck supports information and technology sovereignty by allowing presentation content to remain in readable Markdown. Open formats make content more controllable, reusable and portable than when it is contained solely in a closed application format.

Local processing, offline HTML export, and targeted sharing and privacy features can reduce dependence on third-party presentation services and accidental distribution. Ultimate sovereignty also depends on storage, management and user choices. Read more at OciDeck.

OpenKAT mainly helps with operational, technological and security sovereignty. It brings together digital objects, relationships, observations and findings so that an organization can better understand and monitor its own environment and risks.

Because OpenKAT is open source and can be run itself, an organization can monitor its operation and choose who manages the system. OpenKAT does not provide complete sovereignty: careful management, scope, data protection, knowledge and follow-up remain necessary. Read more at OpenKAT.

A useful approach is: 1. inventory processes, data and dependencies; 2. determine the desired level of sovereignty per system; 3. improve purchasing, contracts, architecture, knowledge and alternatives; 4. Periodically check whether the measures are still working and make adjustments.

Treat this as a cycle. Suppliers, ownership, legislation and technology change. A one-off assessment therefore quickly becomes outdated.

The board is ultimately responsible for direction, risk appetite and acceptance of residual risk. Purchasing, legal affairs, information security, architecture, privacy, management and the process owner each provide a necessary part of the picture.

Because choices often have long-lasting consequences, the book calls sovereignty ‘chefsache’. The subject cannot be confined solely to technology or contract management.

Open source is a form of licensing. The creator or rights holder gives others permission in advance to use, study, copy, distribute and adapt the work.

The right to make adjustments is essential. If modification is not allowed, it is not open source.

The core is legal. Open source is about the way in which copyright is exercised: via a license that gives broad usage rights.

There may be technical and social ideas behind it, but without an appropriate license something is not open source.

It means that the rights holder gives permission to use, study, copy, distribute and modify the source code through an open source license.

The software remains protected by copyright. The license determines which rights and conditions apply.

Open source and free software are about rights: using, studying, sharing and adapting. Freeware usually just means that something is free to use.

Public domain means that there is no longer any copyright restriction, or that the rights holder has waived it to the extent legally possible. That is different from open source.

No. Open source gives many rights, but always within the terms of the license.

These conditions may, for example, concern attribution, retaining license texts or sharing changes under the same license.

The creator or rights holder remains the owner of the copyright, unless that right has been transferred.

Open source does not mean there is no owner. It means that the owner gives broad rights to others through a license.

Yes. Open source does not exclude commercial use. A company may use open source, sell open source services or offer open source software itself.

The price and revenue model are separate from the open source rights.

Open source concerns rights to a work, usually software. Open standards are about agreements, specifications or protocols that can be used by multiple parties.

They can reinforce each other, but they are different things.

An open source license is prior permission given by the rights holder. It states what others may do with the work and what conditions apply.

Without such a license, normal copyright continues to apply and reuse is usually not allowed.

Because copyright arises automatically. In principle, anyone who creates a text, design or software has rights to it.

A license makes it clear what permission others receive. With open source, this permission is broad and arranged in advance.

The code is then visible, but not automatically free to use. Visibility is not consent.

Without a license, another person generally cannot copy, distribute, or modify the code, except in limited legal exceptions.

Permissive licenses provide a lot of freedom and usually impose limited conditions, such as attribution and retention of the license text.

Copyleft licenses also grant broad rights, but may require derivative works to be distributed under the same or a similar license.

Copyleft is a licensing principle where freedom must be passed on. Anyone who distributes the work, often in an adapted form, must give others the same rights.

It is therefore not a waiver of rights, but rather an active way of using rights to maintain openness.

That depends on the license and what you do. Some copyleft licenses may require disclosure if you distribute modified software.

Only internal use does not usually automatically lead to such an obligation, but the precise outcome depends on the situation and license.

Yes, many open source licenses allow commercial use. That is precisely a characteristic of open source.

However, you must comply with the license conditions. Consider mentioning your name, license texts or conditions for distribution.

Yes, open source should allow for customization. Sales are also possible, as long as the licensing conditions are followed.

Some licenses require that you provide or make available the modified source code when you distribute the modified work.

These are ways to keep the original creator and the license visible. Attribution usually means attribution. A notice file contains legal notices. A license header is often at the top of a file.

These obligations ensure that rights and origin remain recognisable.

A patent clause ensures that users also receive permission for relevant patents from contributors under certain conditions.

This can be important because software can be affected not only by copyright, but sometimes also by patent rights.

The main risk is that license conditions are not adhered to. Then you may be using the work without valid permission.

This can lead to repair obligations, legal claims, reputational damage or problems with sales, tendering or auditing.

Open source compliance means that an organization knows which open source it uses, which licenses come with it and what obligations apply.

It is mainly normal legal and organizational management: registering, checking, complying and being able to explain what has been used.

No, not because of the open source nature. Security depends on design, maintenance, control, use and monitoring of vulnerabilities.

Openness enables control, but is not an automatic guarantee of security.

No. Everyone can often make proposals, but that does not mean that everyone can simply make changes.

For serious projects, administrators assess which contributions are included. Reliability depends on governance and maintenance, not just the license type.

No. Support can be voluntary, community-driven or commercial. Many companies provide paid support for open source.

The license determines the rights to the work; support is a separate service.

No. Open source is about usage rights, not about price.

An open source product may be free to download, but support, hosting, certification, training or customization may be paid.

No. Free is about price. Free is about rights.

A free product can be strictly closed. An open source product gives rights to use, study, share and modify.

No. Open source can be created by volunteers, but also by companies, governments, universities and foundations.

The license says nothing about professionalism. You have to assess this based on quality, management and context.

No. Open source can be very professional and commercial software can be poorly maintained. The reverse is also possible.

Professionalism is evident from maintenance, documentation, governance, quality and agreements, not from open or closed licenses alone.

Openness means that everyone can watch, including malicious parties. But it also means that control by users, researchers and suppliers is possible.

Security does not come from secrecy alone. It requires maintenance, response and careful use.

No. Legal rights are relevant to everyone: users, administrators, purchasers, lawyers, auditors and policy makers.

Developers often work with the code, but organizations also benefit from transparency, freedom of choice and auditability.

That may be a trade-off, but it is not automatically a disadvantage. Open source is about consciously determining which parts you want to share and under what conditions.

Sometimes open sharing is strategically useful, for example to promote collaboration, trust or standardization.

That varies per project. Control can come from maintainers, users, security researchers, audits, automatic scans and organizations that deploy the software.

Open source makes such control possible, but does not organize it by itself.

That depends on the situation. The project administrators can create an update, but the user or organization must also apply that update.

Open source does not change the fact that anyone who uses software remains responsible for careful management.

That varies greatly. Active projects can respond quickly; abandoned projects cannot. The same also applies to closed software.

Therefore, do not only look at the license, but also at maintenance, reporting process and release practice.

Supply chain risks arise when you are dependent on parts from others. If such a part is vulnerable, malicious or poorly maintained, this can have consequences for your own product.

This risk is not exclusive to open source, but open source often makes dependencies more visible.

Dependencies are parts on which a product is based. With software, these are often libraries or packages from others.

They are important because rights, vulnerabilities and maintenance of those parts also influence your own use.

Look at the license, maintenance, documentation, how changes are reviewed and how security alerts are handled.

Reliability is a combination of legal clarity, quality and management.

Healthy signals are clear licensing information, recent updates, understandable documentation, an active reporting process and visible decision-making.

It also helps if several people or organizations contribute, so that the project is not completely dependent on one person.

Look for old releases, unanswered notifications, missing licensing information, unclear maintainers, or no response to security issues.

These are project risks. They occur in open and closed software, but in open source they are often more visible.

During a security audit, someone specifically assesses whether there are any vulnerabilities or weak spots. With open source, the source code can be examined directly.

An audit is a snapshot. Maintenance and follow-up will then continue to be necessary.

A SBOM is a software bill of materials: an overview of used software components.

Such an overview helps to manage licenses, vulnerabilities and dependencies. It is especially useful for organizations that need to be able to explain what they are using.

An open source project is created when a rights holder publishes work under an open source license. This often includes documentation, a place for contributions and a way of decision-making.

The license is the legal basis; the community and working method determine how the project continues to grow.

This is usually done by the maintainers or administrators of the project. They assess whether a contribution is in line with the quality, direction and agreements of the project.

Open source does not mean that every change automatically becomes part of the official project.

A maintainer is someone who manages a project. That person or group reviews contributions, makes releases, monitors direction, and maintains documentation or processes.

In open source, that role is important because the rights are broad, but collaboration still requires organization.

A contributor is someone who contributes to a project. This could be code, but also documentation, translation, testing, design, explanation or reporting problems.

Open source contributions are therefore broader than programming.

A fork is your own copy of a project on which someone can continue working independently. That’s possible because open source allows for modification and distribution.

Sometimes an improvement is later reflected in the original project. Sometimes a fork grows into its own direction.

That is a proposal to include a change in a project. The administrator can review, discuss, adjust or reject the change.

It is a practical way to organize collaboration around open source.

Community governance is about the agreements with which a project makes decisions. Consider who can participate in decision-making, how conflicts are resolved and how new administrators are appointed.

The license gives rights; governance regulates cooperation.

In community-led projects, direction mainly lies with a community of participants. In company-led projects, a company often has a large or decisive role.

Both forms can work well, as long as it is clear who decides and under what conditions.

That depends on the governance. Some projects have clear decision rules, codes of conduct or foundations. Other projects are more informal.

Good agreements are important because open rights do not automatically mean that everyone agrees.

Projects stop when maintainers run out of time, funding is lacking, the need disappears or a better solution arises.

That is not unique to open source. The difference is that with open source, others can sometimes continue with a fork.

Companies do not necessarily make money from exclusively selling the code, but from services surrounding it. Consider hosting, support, implementation, management, training, certification or customization.

The open license and the business model are two different layers.

Common models include paid support, managed hosting, consultancy, certification, training, dual licensing and open core.

The starting point is often: the basic rights are open, but convenience, security or additional services may be paid for.

Open core means that the core of a product is open source, while some additional features are closed or paid.

That can work, but it requires clear communication. Users need to know which part is open and which part is not.

Dual licensing means that the same work is available under two different licenses. For example, an open source license and a commercial license.

This can give organizations a choice, but is only possible if the rights holder has the rights to offer both licenses.

Managed hosting or SaaS means that someone offers open source software as a service. The user then does not have to install and manage the software himself.

The software can be open source, while the service surrounding it is paid.

Companies can do this to increase trust, stimulate collaboration, set a standard or accelerate adoption.

Open source can also help reduce dependency on a single supplier and build an ecosystem.

Because others are allowed to build on existing work. They don’t have to start over again and can share improvements.

The license makes that collaboration legally possible.

Open source can reduce dependence on one supplier because users have rights to study the software, modify it and have it managed elsewhere.

This does not mean that switching is always easy, but the legal basis is less closed.

Open source is interesting when collaboration, transparency, verifiability, reuse or independence are important.

It is especially strong in shared infrastructure, public values ​​and situations where trust requires more than a supplier promise.

Open source is less suitable when the rights holder wants to limit distribution, access or modification. That is a strategic choice about control.

It is also less appropriate if an organization wants to grant rights without being prepared to clearly record licensing conditions and management.

Startups can build on existing components more quickly and gain trust more easily through openness. They can also develop a community or market around an open project.

They must be conscious of licensing, positioning and their revenue model.

For governments, open source can contribute to transparency, auditability, reuse and less dependence on one supplier.

This fits well with public accountability, provided management, safety and legal compliance are properly arranged.

Education can use open source to learn from real examples, share materials and let students contribute to existing projects.

Because adjustment is allowed, teaching materials or software can be better aligned with educational practice.

Open source can help because organizations are not completely dependent on closed knowledge or one supplier. They can have it checked how something works and have it adjusted.

Sovereignty requires more than just open source, but open rights are an important building block.

Open source makes visible under what conditions a work may be used and, in the case of software, what the source code looks like.

This makes control and explanation easier. Transparency only really arises when documentation and governance are also clear.

Because others are allowed to use and adapt existing work, not everyone has to recreate the same thing.

This can reduce waste and share maintenance, especially when multiple parties have the same problem.

Open source shows how an organization works, what quality it strives for and what it stands for. People can easily contribute or get to know what is happening.

This can be attractive for professionals who value openness and craftsmanship.

Competitors can collaborate on parts that are needed by everyone, without those parts having to be the distinguishing product.

The license provides clarity in advance about rights, so that collaboration is less dependent on separate agreements.

Public infrastructure requires trust, continuity and verifiability. Open source can help because the basis is not completely behind closed doors.

This makes independent control and joint maintenance more possible.

In these areas, open source can contribute to verifiability, reuse and independent research.

At the same time, good governance, data management, security and legal assessment remain necessary. Open source is a basic requirement for certain forms of control, not a total solution.

Start with the license: is the use you have in mind allowed? Then look at maintenance, documentation, quality and dependencies.

A popular package is not automatically suitable. The choice must fit the purpose, risk and maintenance context.

Check the license, origin, maintenance status, vulnerabilities and necessity. Also ask whether the part is really necessary.

Each dependency adds rights, obligations and management.

Record which components are used, which version, which license and what the component is included in.

Also make sure it is clear who is responsible for updates and compliance with conditions.

Use a combination of registration, periodic checking, and dependency scanning tools.

Most importantly: agree on who will review notifications and who will decide on updates or replacements.

There are many tools that map dependencies, licenses and vulnerabilities. Examples include scanners in development platforms, package managers and specialized compliance tools.

The tool is just a tool. The organization still has to make choices and arrange follow-up.

Please read the contribution instructions and license first. Describe clearly what you want to improve and why.

A good contribution can be code, but also documentation, testing, translation or a clearly described problem.

This makes sense if you want others to be able to use, monitor, share, and modify the work.

Make that choice consciously: determine purpose, license, maintenance, governance and what you do or do not expect from contributions.

First decide what you want to allow and protect. If you want broad reusability, look at permissive licenses. If you want freedom to be passed on, look at copyleft.

Preferably use existing, known licenses instead of writing text yourself.

Provide clear documentation, a friendly way to ask questions, clear decision-making and realistic expectations.

A community is not created just by putting code online. It requires attention, trust and maintenance.

Divide rights and responsibilities. Document processes, make releases portable and give multiple trusted people management rights.

This increases continuity and makes the project less vulnerable.

An Open Source Program Office, often called OSPO, is a team or function that organizes open source use and contributions within an organization.

It helps with policies, licensing, collaboration, communities, and responsible publishing.

At a minimum, policies are needed for usage, contribution, publishing, license control, and security tracking.

The policy must be practical: people must know what is allowed, when to ask for advice and who decides.

Explain in plain language what copyright, licenses and obligations mean. Use examples from your own work.

Training should not only be legal, but also practical: what do you register, what do you check and where do you ask for help?

All, depending on the choice. Legal looks at rights and obligations. Security looks at vulnerabilities and management. Engineering looks at quality and application. Procurement looks at contracts and suppliers.

Open source often affects multiple responsibilities at the same time.

Make sure it is clear which parts have been used, which licenses apply, which checks have been carried out and which decisions have been made.

Auditable mainly means: being able to explain afterwards what happened and why.

Consciously include open source in requirements, assessment criteria and contract conditions. Don’t just ask about a product, but also about rights, portability and management.

This way you prevent openness from remaining just a wish and not ending up in the assignment.

See support as a supplement to open source rights. The contract may contain agreements about response times, updates, liability, hosting or management.

The software can be open, while the support is professional and paid.

Don’t just look at licensing costs. Also include management, support, training, integration, migration, compliance and maintenance.

Open source can be cheaper, but the real value often lies in control, flexibility and less dependency.

Treat open source as part of normal risk management. Look at licensing, maintenance, security, dependencies and continuity.

The risk is not that something is open source, but that use occurs unconsciously or unattended.

Don’t just measure saved costs. Also look at reuse, speed, transparency, avoided dependency, collaboration and quality of control.

Some value is financial, other value is in autonomy and trust.

No. Open source provides important freedoms, but does not automatically say anything about all ethical choices regarding use, impact or governance.

Openness can help to enable discussion, control and accountability.

Not completely. Open source licenses allow broad use and usually do not restrict what someone uses the work for.

Anyone who wants to limit abuse quickly ends up going beyond classic open source and has to think about other legal or organizational means.

Classic open source licenses do not restrict purposes of use. They give rights to everyone, even if the creator considers some applications undesirable.

There are licenses with ethical usage restrictions, but they are generally not considered open source in the strict sense.

Open source gives others control over their own use: they can study, adapt and share. The original creator therefore relinquishes some exclusive control over distribution and modification.

That is not a mistake, but exactly the choice that makes open source special.

Open source can support public values ​​such as transparency, auditability, reuse and independence.

But public values ​​also require good governance, accessibility, safety, financing and responsibility.

This varies greatly per project. Some communities are open and helpful, others are difficult to access or depend on informal networks.

Inclusion requires active attention to language, behavior, documentation, decision-making and safe participation.

That is an important issue. Much digital infrastructure is widely used, but not always widely financed.

Open source makes use possible, but maintenance requires time, money and responsibility from parties that depend on it.

Open source can spread power because users have more rights than just purchasing what a supplier offers. They can have it checked, adjusted or switched.

This strengthens autonomy, but only if there is also knowledge, capacity and governance to utilize those rights.

Complete prevention is usually not possible within classical open source. Projects can choose suitable licenses, governance, commercial agreements and a culture in which contributing back is normal.

Users can also take responsibility by returning maintenance, money or knowledge.

Open source remains important for digital infrastructure, government, education, cloud, AI and security. The core remains legal: giving rights to use, study, share and adapt.

The big challenge is sustainable management: ensuring that open projects are not only used, but also maintained and managed responsibly.

MIAUW stands for Methodology for Information Security Research with Audit Value. It is a way to conduct security research, such as a pen test, in a structured and verifiable manner.

The goal is that an organization not only receives a report, but can also better demonstrate what has been researched, how it was done and what conclusions follow from it.

Read more at MIAUW.

Many security investigations produce useful findings, but are difficult to assess afterwards. Sometimes it is unclear what exactly fell within the scope, which steps were carried out or what evidence supports a conclusion.

MIAUW helps to better record these components before and during the research. This makes the research more useful for recovery, accountability and audits.

Read more on MIAUW and in What does audit value mean?.

No. A pen test is a form of security research. MIAUW is a methodology to better structure, record and make such research more controllable.

A pen test can therefore be carried out according to MIAUW, but MIAUW is broader than just carrying out technical tests.

Also read What is a pen test? and MIAUW.

Audit value means that an investigation can be properly assessed afterwards. An auditor or other evaluator must be able to see what has been agreed, what has been tested, what evidence there is and how conclusions have been reached.

This makes an investigation not only useful for technology, but also for governance, compliance and accountability.

Read more at MIAUW and What is an auditor’s report at MIAUW?.

MIAUW is intended for clients, penetration testers, auditors, compliance specialists and directors.

The client gains more control over the research. The researcher receives a clear structure. The auditor receives more verifiable information. Directors gain more certainty about what a report does and does not say.

Read more at MIAUW.

No. No methodology can guarantee that a system is secure.

MIAUW does help to better conduct security research, better document it and better use it for improvement. So it increases the quality and usefulness of research, but does not replace good security management.

Also read What is central to a MIAUW study?.

The focus is on clear agreements, a clear scope, imitable evidence, reproducible findings and reporting that is useful for different target groups.

A technical team wants details to solve problems. Management wants to know what the risk means. An auditor wants to be able to assess whether the investigation has been carried out carefully.

Read more at MIAUW.

Scope means: what is and is not part of the research. Think of systems, domains, applications, accounts, networks, periods and research questions.

A clear scope prevents misunderstandings. Without a scope, it is difficult to say afterwards whether something was deliberately left out of view or accidentally not examined.

See also How does OpenKAT handle scope and permission?.

Evidence makes findings verifiable. A report should not only say that something is wrong, but also show what that conclusion is based on.

Evidence may include logs, screenshots, command output, configuration data, or other records. Naturally, sensitive information must be handled with care.

Also read What does evidence-based security mean?.

A finding is an identified problem, risk or point of attention from the research.

A good finding describes what has been found, why it is important, what evidence is involved, what the impact could be and what measure helps to reduce or solve the problem.

Also read What is the difference between a risk and a vulnerability?.

A vulnerability is a weak spot. A risk is about what that weakness can mean for the organization.

A vulnerability in a test system without sensitive data often has a different risk than the same vulnerability in a public system with personal data. So context is important.

Also read What is a finding?.

No. Large organizations often have more formal audit and compliance requirements, but smaller organizations also benefit from clear agreements, better evidence and useful reporting.

MIAUW can actually help to make security research more understandable and transferable.

Read more at MIAUW.

An auditor’s statement can help to demonstrate that an investigation has been carried out according to agreements, without all technical details having to be widely shared.

This is useful when a complete report is too sensitive for wide distribution, but an organization must demonstrate that serious and verifiable research has been conducted.

Also read If I do a pentest with MIAUW, do I have to make it public?.

A pen test, or penetration test in full, is a controlled security investigation. Researchers try to find vulnerabilities before malicious parties do.

A pen test is not a random attack. There are agreements about scope, permission, approach, reporting and due care. The researchers use techniques that attackers can also use, but with the aim of improving security.

In the Methodology for Information Security Research with Audit Value (MIAUW), we have extensively discussed a definition led by Mr. V.A. the Pous. This resulted in this definition:

‘An offensive security investigation to be carried out by our own personnel or third parties, which involves a controlled search for vulnerabilities in one or more secured network and information systems or parts thereof, which can be used to break into these systems and/or which can, without intention or autonomously, disrupt the data processing of the organization under investigation or otherwise have adverse consequences.’

Also read What is MIAUW?.

No, that’s not necessary. The aim of MIAUW is to put the client first. If you pay for a report, it makes sense that you have control over the product you buy. That is why MIAUW says something about the supplier: he may not impose restrictions on distribution on the client. It is described like this:

No restrictions are imposed on the client with regard to dissemination, publication or storage of the report and the underlying documents. Excluded from this are financial data relating to the conduct of the research, such as hourly rates, prices and invoices.

The greater goal is that with a pen test you can also demonstrate that the important matters have been properly arranged. That is difficult if you are not allowed to show or provide the research to others. Financial information about the research does not need to be shared, because it says nothing about the security status.

Is there too much sensitive information in the report to share it widely? Then an auditor’s report can help. This allows you to demonstrate that the study was conducted and what the main outcome was, without distributing all the technical details.

In short: the client determines what level of information is shared with partners, regulators or others, without being hindered by the supplier.

Also read What is an auditor’s report at MIAUW?.

OpenKAT is the Open Vulnerability Analysis Tool. It is open source software that helps organizations map their digital landscape and make vulnerabilities, misconfigurations and risks visible.

OpenKAT is all about insight: what do we have, what is visible, what is changing and what do we need to do something with?

Read more at OpenKAT.

OpenKAT helps to better understand your digital outside and inside. It collects information about systems, domains, software and settings and converts it into actionable insight.

In plain language: OpenKAT helps see where digital doors, windows and locks are located and which of them need attention.

Read more at OpenKAT.

The attack surface is everything an attacker might try to use to gain access or cause damage.

Think of websites, mail servers, cloud environments, APIs, VPNs, old domains, forgotten test environments and incorrectly configured services. The better you know that surface, the more targeted protection you can provide.

Also read Why is continuous insight important?.

Digital environments are constantly changing. Systems are added, software is updated, settings change and new vulnerabilities are discovered.

A one-time scan is therefore a snapshot. Continuous insight helps to see changes and respond faster when something deteriorates or becomes vulnerable again.

Also read Can OpenKAT show changes over time?.

No. OpenKAT and pen testing complement each other.

OpenKAT provides continuous technical insight and can collect many signals. A pen test is a targeted investigation by people, with context, creativity and depth. OpenKAT can help to better target pen tests and better track results.

Also read What is a pen test? and OpenKAT.

No. No security product finds everything automatically.

OpenKAT helps to collect and assess a lot of information in a structured manner. But good scope, interpretation, management and follow-up remain necessary. Human context remains important.

Also read How does OpenKAT help with prioritization?.

In OpenKAT, a rogue is a small research task or scanner that collects specific information. For example, it can check something about DNS, TLS, software versions or other technical properties.

The idea is modular: many small tasks together provide a richer picture of the digital environment.

Also read What is normalization in OpenKAT?.

A finding is a signal that requires attention. This could be a vulnerability, but also an incorrect setting, missing security measures or deviation from policy.

A finding is not always immediately an incident. It is primarily a reason to assess what it means and what follow-up is needed.

Also read How does OpenKAT help with prioritization?.

Evidence-based security means that conclusions are based on recorded data, not just on feelings or loose assumptions.

OpenKAT helps by saving observations and linking them to findings. This makes it easier to see what a conclusion is based on and how the situation changes over time.

Also read Why is evidence important in MIAUW?.

Compliance is about demonstrating that you meet rules, standards or agreements. OpenKAT can link technical observations to policies or standards.

This makes it clearer which technical findings are also administratively or legally relevant. This helps with audits, reporting and prioritization.

Also read Can OpenKAT help with NIS2?.

No. Security specialists need the technical details, but OpenKAT is also useful for administrators, auditors, compliance teams and directors.

Each role looks differently at the same reality: technical details for solving, overviews for steering and evidence for accountability.

Read more at OpenKAT.

Yes. OpenKAT is open source and can be used yourself. This does require technical knowledge, management and careful design.

Some organizations therefore opt for self-management. Other organizations prefer to work with a partner for hosting, design, management or support.

See also Partners and OpenKAT.

OpenKAT is a security tool and should be used carefully. Scanning is only done within an agreed scope and with permission.

The results can be sensitive because they say something about vulnerabilities and institutions. So protect that information well and only give access to people who need that information.

Also read How does OpenKAT deal with privacy?.

OpenKAT works with objects that can be examined. This could, for example, be a domain name, IP address, website, server, certificate or other technical component.

By recording such objects separately, OpenKAT can establish relationships: which website belongs to which domain, which certificate belongs to which service and which finding belongs to which component.

Read more at OpenKAT.

Scanners often produce rough output. Normalizing means converting that output into data that OpenKAT can understand and compare in a fixed way.

This is important because OpenKAT wants to combine information from different sources. Only when data is neatly structured can you link it to objects, findings, standards and timelines.

Also read What does evidence-based security mean?.

A vulnerability scanner usually looks for specific technical vulnerabilities. OpenKAT is broader: it can combine data from multiple sources, establish relationships, show changes over time and link findings to policies or standards.

OpenKAT can therefore use scanners, but is itself primarily a platform for bringing observations, context and follow-up together.

Read more at OpenKAT.

OpenKAT is intended for research within an agreed scope. So you only scan systems for which you have permission and for which it is clear what can be examined.

This is important for legal, technical and organizational reasons. Security research without a clear scope can cause risks and damage trust.

See also What is the scope of a MIAUW investigation?.

Yes. An important idea behind OpenKAT is that you don’t just want a snapshot, you also want to see how the situation is changing.

This helps with questions such as: has a problem been solved, has it returned, has something new emerged and is the security situation getting better or worse?

Also read Why is continuous insight important?.

Not every finding has the same urgency. A technical problem on an unimportant test system is often less serious than the same problem on a public system with sensitive data.

OpenKAT helps by linking technical signals to context, policy and standards. This allows an organization to better determine what needs to be addressed first.

Also read How does OpenKAT help with compliance?.

OpenKAT can help with the practical side of demonstrable digital resilience: gaining insight into systems, vulnerabilities, misconfigurations and changes over time.

NIS2 is not only about technology, but also about governance, risks and demonstrability. OpenKAT can provide technical support for this, but does not replace a complete NIS2 program.

Also read How does OpenKAT help with compliance?.

OpenKAT mainly examines technical data, but the results can be sensitive. A vulnerability or configuration error report can be misused if it ends up in the wrong place.

That is why it is important to limit access, protect results well and only scan within a clear scope.

Also read the privacy policy of this website and Is OpenKAT safe to use?.

Individual scan results are often difficult to interpret. Relationships make it clear how components are related: which domain belongs to which website, which service runs on which system and which finding belongs to which object.

These relationships make OpenKAT more than a list of notifications. It becomes a model of the digital environment that helps to better understand causes, impact and follow-up.

Read more at OpenKAT.

Yes. OpenKAT is interesting because it can combine information from different sources. Consider scanners, external data sources, configuration checks and own research tasks.

The goal is not to replace every tool, but to better bring results together and make them useful for analysis, monitoring and accountability.

Read more at OpenKAT.

OciDeck is a presentation program that focuses on content. You build slides from clear slide shapes, data and text, instead of manually sliding objects across a canvas.

Read more at OciDeck.

OciDeck is intended for people who see presentations as knowledge carriers. Think of trainers, researchers, security professionals, developers, auditors, policymakers and organizations that want to keep control of their information.

It is especially interesting when content, reuse, verifiability and safe sharing are important.

Read more at OciDeck and Features of OciDeck.

Many presentation software starts with a blank canvas. You drag text boxes, images, and shapes into place.

OciDeck starts with the content. You choose the type of slide, fill in the content and let the presentation arise from it. This makes slides easier to check, reuse and export.

Also read Why Marp is important to OciDeck.

Marp is a way to create presentations with Markdown. Markdown is a simple text notation.

Voor OciDeck is Marp belangrijk omdat de presentatie daardoor gewone tekst blijft. Dat maakt wijzigingen controleerbaar en zorgt dat de inhoud niet opgesloten zit in een gesloten bestandsformaat.

Read more at Why Marp is important to OciDeck.

Not necessarily. OciDeck offers structured editors per slide type. So you can work without writing Markdown all the time.

Markdown is primarily the open basis for the presentation. Anyone who knows Markdown can benefit from this, but it is not a strict requirement for every use.

Also read What is Marp?.

Presentations often contain more sensitive information than people think: names, email addresses, customer details, tokens, screenshots, speaker notes or technical details.

OciDeck helps to make such information visible earlier, before a presentation is shared or exported.

Read more at Privacy features in OciDeck.

OciWacht searches locally for potentially sensitive data in a presentation. Think of identification numbers, email addresses, telephone numbers, tokens, keys or other sensitive patterns.

For each finding, the creator can choose what to do with it: accept, mark or omit from presentation and export.

Read more at Privacy features in OciDeck.

No, not for the normal processing of your presentation. OciDeck web runs in your browser: the Flutter web app is loaded from the server and then editing, live preview, OciWacht, export to PDF/PPTX/HTML and the CVSS builder happen client-side. Deck content is not sent to a backend for processing.

There is also no telemetry or analytics built in. The OciDeck hosting server therefore gets no application-level insight into your deck, edits, privacy findings or exports.

There are nuances. Like every webhost, the server may have ordinary access logs, such as IP address, time, requested files and user-agent. That shows that someone loaded the app, but not what that person does in OciDeck.

There is also an optional fetch proxy for URL import when a source does not allow CORS access. Only when you open such a non-CORS URL through that proxy does the server see the URL you entered and relay the bytes.

Other outgoing connections are user-initiated and go to destinations you choose or configure yourself, such as optional AI assistance, WebDAV/Nextcloud, a CVE database, secmodule provisioning or a URL you import yourself.

If you want to use OciDeck in the browser, go to ocideck.nl.

Read more at Privacy features in OciDeck.

No. No scan finds everything.

OciWacht is a tool to identify risks earlier and share them more consciously. The creator remains responsible for the content and must always think for himself in sensitive presentations.

Also read Why are privacy features in OciDeck important?.

Not every slide is intended for every audience. OciDeck can help to determine per presentation and per slide how widely information may be shared.

OciDeck can thus help prevent an internal slide from accidentally ending up in a broader presentation or export.

Read more at Share at the right level.

TLP stands for Traffic Light Protocol. It is a color system to indicate how confidential information is and with whom that information may be shared.

You don’t need to know the abbreviation to understand the principle. The practical question is: who is allowed to see this information?

Read more at Share at the right level.

Yes. Graphs in OciDeck remain connected to data. This makes them more controllable and less dependent on screenshots or manually created images.

This is useful for research, reports, dashboards and presentations where figures must remain correct.

Read more at Features of OciDeck.

Yes. Checklists can be checked off while presenting.

This is useful for training, workshops, demonstrations, security reviews and reports in which progress must be visible. The checklist then becomes part of the story, not something in addition to the presentation.

Read more at Features of OciDeck.

Yes. OciDeck focuses on working from a single source and exporting to usable formats such as PDF, PPTX and standalone offline HTML.

The advantage is that the same content can be used for different purposes, without having to manually build new copies each time.

Read more at Features of OciDeck.

Yes. OciDeck is open source. The source code is in Forgejo:

https://pawprint.vigilis.online/LibreKAT/Ocideck

Also read OciDeck.

Slide shapes are fixed types of slides, such as a title, list, table, graph, code example, question, timeline or dashboard.

By working with slide shapes, the creator has to scroll less manually. The content is central and OciDeck can display, control and export that content more consistently.

Read more at Features of OciDeck.

Yes. OciDeck supports slides with source code and syntax highlighting. Code remains real text instead of a screenshot.

This is useful for technical presentations, training and security reports in which code must remain readable and auditable.

Read more at Features of OciDeck.

Yes. OciDeck can use free Markdown slides including Mermaid diagrams and LaTeX math.

This means that charts and formulas can be saved as source content, rather than as a separate image that is difficult to change later.

Read more about what Marp Markdown makes possible.

Markdown mode is intended for users who want to work directly in a deck’s text source. This can be useful for search and replace, quick text changes, or technical checking.

You don’t always have to use Markdown mode. The structured editors remain there for those who prefer to work per slide.

Also read What is Marp?.

OciDeck includes an optional MIAUW pen test module. This module is intended for reports according to the Methodology for Information Security Research with Audit Value.

Think of finding slides, summaries, checklists, scope overviews and reporting support. The module is off by default and is intended for situations where MIAUW is really relevant.

Read more at Features of OciDeck and What is MIAUW?.

Offline HTML export means that a presentation can be carried or shared as a standalone HTML version, without the need for network access during display.

This is useful for training, demonstrations and environments where you do not want to be dependent on cloud presentations or external services.

Read more at Features of OciDeck.

Yes. OciDeck supports presenting with, among other things, full-screen display, keyboard navigation, timer, notes, rehearsal mode and dual-screen presenter.

This makes OciDeck not only an editor, but also a tool for actually giving presentations.

Read more at Features of OciDeck.

Yes. OciDeck can work with speaker notes and separate notes for participants.

This is useful because not all information needs to be on the slide itself. A speaker may need extra context, while participants need a neat summary or reference.

Read more at Features of OciDeck.

Yes. OciDeck can use Nextcloud/WebDAV as a source for OciDeck packages and Marp Markdown decks.

This suits organizations that prefer to keep documents under their own management or in their own collaborative environment.

Read more at Features of OciDeck.

OciDeck focuses on an accessible interface, including keyboard controls, screen reader labels, text scale and slide change announcements.

Accessibility is also about structure. Because slides consist of real content, it is easier to keep that content understandable and verifiable.

Read more at Features of OciDeck.

The LibreKAT Foundation works on open, controllable and verifiable information security. The foundation supports projects, knowledge sharing and collaboration around digital security.

This is not just about software. LibreKAT also wants to contribute to better working practices, more transparency and a community in which people can improve digital security together.

Read more at About the LibreKAT Foundation.

Digital security is too important to be completely dependent on closed systems, uncontrollable processes or loose promises. Organizations need to be able to understand, control and improve how their security works.

LibreKAT exists to promote that. The foundation encourages open technology, knowledge sharing and collaboration between people who want to increase digital resilience.

Also read What are the goals of the LibreKAT Foundation? and About the LibreKAT Foundation.

No. LibreKAT is a foundation and has no profit objective. The foundation can collaborate with companies, governments, researchers, volunteers and social organizations.

The primary objective in collaboration is to contribute to open, sustainable and verifiable digital security.

Read more at About the LibreKAT Foundation.

Libre refers to freedom. Not just free use, but above all the freedom to study, control, adapt and share technology.

This is important for information security. If you want to rely on a system or method, you must be able to see how it works and how decisions are made.

That ties in with the core values ​​of the LibreKAT Foundation.

The LibreKAT Foundation wants to improve digital security by encouraging open, controllable and verifiable information security.

In concrete terms, this includes:

• development and use of open source software and hardware for secure digital infrastructures;
• transparency and reproducibility in security processes;
• research, training and activities on digital resilience;
• connection between citizens, companies, government and social organizations.

Read more on About the LibreKAT Foundation and on the homepage of the LibreKAT Foundation.

LibreKAT is the foundation. OpenKAT is an open source vulnerability analysis product.

The names are similar, but do not mean the same. The foundation can support OpenKAT and OpenKAT fits in with LibreKAT’s mission, but OpenKAT is not the foundation itself.

Read more about LibreKAT Foundation and OpenKAT.

Important projects on this site are OpenKAT, MIAUW and OciDeck.

OpenKAT helps make vulnerabilities and digital risks visible. MIAUW helps to make information security research verifiable and audit-worthy. OciDeck helps with structured presentations, reports and secure information sharing.

Read more about OpenKAT, MIAUW and OciDeck.

Open source makes control possible. People can see how software works, find errors, suggest improvements and reduce dependency on a single supplier.

Open source is not an automatic guarantee of security. It is an important condition for transparency, cooperation and restorability.

Read more about the principles on About the LibreKAT Foundation.

LibreKAT is for everyone who wants to make digital security open, verifiable and more explainable.

Think of security professionals, developers, administrators, auditors, researchers, governments, companies, educational institutions, social organizations and involved citizens.

Read more at About the LibreKAT Foundation.

Yes. You can participate in several ways: contributing code, improving documentation, testing, translating, asking questions, sharing experiences or helping with meetings and community activities.

You don’t have to know everything technically to make a valuable contribution. Good questions, practical experience and clear explanations are also important.

Contact us at Contact.

This is possible if the collaboration fits the foundation’s objectives. LibreKAT is looking for collaboration that contributes to open, sustainable and verifiable digital security.

Examples are knowledge sharing, research, open source development, documentation, training or practical applications of the projects.

See also Partners and Contact.

Important values ​​are safety, freedom, openness, sovereignty, integrity, knowledge sharing, cooperation, humanity and continuity.

In plain language: LibreKAT wants digital security to be verifiable, fair, sustainable and usable for the people and organizations that depend on it.

Also read the article About our core values.

Use the contact page if you have a question, want to contribute or discuss collaboration.

Try to briefly describe what your question is about: foundation, MIAUW, OpenKAT, OciDeck, collaboration, press or a technical contribution. Then it will be clearer more quickly who can respond.