Frequently asked questions

A Just Culture is an organizational culture in which people can report safety problems, errors and near-incidents without automatically looking for someone to blame. The organization uses the information to understand what happened and to improve people, technology, working methods and organization.

That does not mean that every behavior is acceptable. A Just Culture makes it clear in advance where the boundaries lie and assesses behavior carefully, consistently and in context. European aviation rules define this as a culture in which employees are not punished for actions consistent with their training and experience, while gross negligence and intentional violations are not tolerated. See Regulation (EU) 376/2014.

The modern elaboration comes from the safety science surrounding complex, high-risk organizations. Psychologist James Reason described Just Culture in 1997 as part of an informed safety culture, in addition to a reporting culture, learning culture and flexible culture.

Aviation in particular put the principle into practice. Accidents and near misses can only be investigated when pilots, air traffic controllers, technicians and others dare to share information. Aviation organizations therefore developed reporting systems that do not automatically punish common mistakes, but do set limits for intentional or reckless behavior. SKYbrary describes this development; the European Union established the principle in rules for occurrence reporting in civil aviation in 2014.

Afterwards, Just Culture has also been applied in healthcare, railways, energy and other sectors where learning from weak signals is important. It is therefore not an aviation procedure that is copied one-on-one, but a broader principle for dealing with errors and risks in a fair and learning-oriented manner.

No. A Just Culture prevents an honest report, simple mistake or unintentional violation from automatically leading to punishment. Coaching, extra support or an adapted working method may be necessary; These are measures to ensure safe working, not automatic punishments.

In cases of intentional misconduct, sabotage, deliberate recklessness or serious disregard of a clear risk, action against a person may be appropriate. This first requires an honest investigation into facts, circumstances, training, available resources and comparable previous decisions. Just Culture also does not grant legal immunity: applicable law continues to apply. This balance can be found in Article 16 of Regulation (EU) 376/2014.

No. A complete ’no blame’ model can leave responsibility and unacceptable behavior out of the picture. Just Culture seeks a fair boundary between behavior from which the organization must learn and behavior from which it should address a person.

The first question is not ‘who can we punish?’, but ‘what happened, why did this action seem logical at the time and what circumstances played a role?’. Only then does the question arise whether the behavior fell within the previously known and consistently applied limits.

No. Employees remain responsible for acting carefully, reporting and cooperating in investigations. Managers are responsible for realistic goals, sufficient resources, clear boundaries and repairing structural problems.

Accountability means that choices and circumstances can be discussed and controlled. Assigning blame is a judgment about culpability. A Just Culture separates the two, so that responsibility does not disappear but is distributed more fairly.

Human error is unintentional. Risky behavior can arise because someone underestimates a risk, an unsafe habit has become normal or goals conflict with each other. Reckless conduct involves a conscious and serious disregard of an obvious risk. Intentionally harmful actions form yet another category.

These words are not automatic outcomes. A careful investigation looks at training, available information, workload, technical design, procedures, previous signals and how others acted in the same situation. The severity of the damage alone does not prove that the conduct was reckless.

Employees are required to report errors, risks and near-incidents in a timely manner, to express uncertainty, to cooperate in research and to share relevant knowledge. Managers are expected to listen without premature judgment, protect reporters, investigate facts and context and provide feedback on what happens to a report.

The organization should repair structural causes, treat comparable cases equally and make it clear in advance which behavior is unacceptable. Concealing, retaliating, judging the outcome alone or allowing known risks to continue do not fit in with a Just Culture.

Information security depends on early signals. Think of an opened phishing link, incorrectly configured access, an almost leaked file, an unsafe emergency solution or a vulnerability that someone accidentally discovers. Fear of punishment or damage to reputation may lead to such information being reported too late or not at all.

A Just Culture lowers that threshold and enables faster investigation and recovery. This does not replace security measures, incident response, reporting obligations or action against abuse. It ensures that the organization receives more reliable information to use those instruments in a targeted manner.

People work within goals, tools, procedures, time pressures and technical limitations. If multiple people can make the same mistake, addressing the last person alone is not a complete solution. The same conditions can then cause the problem again.

Therefore, a Just Culture also examines system design, access rights, training, workload, supervision, conflicting goals and previous signals. This does not exclude individual responsibility. It does prevent a visible human action from concealing deeper causes from view.

A pen test can affect the behavior of employees, administrators or suppliers. MIAUW requires that a finding be substantiated with evidence, scope and context. A report should therefore describe observable facts and consequences and not attribute intentions or personal culpability without investigation.

Just Culture helps use the outcome for recovery: which technical or organizational conditions made the problem possible, which measure reduces recurrence and who owns that measure? If individual action appears to be appropriate, this requires a separate and fair process; a pen test score alone is not proof of this.

First describe what demonstrably happened, when, within what scope and with what consequence. Then record relevant circumstances, such as available information, instructions, workload, access rights and technical security. Make it clear what is fact, statement and unconfirmed assumption.

Use a name only when identification is necessary and proportionate. Wordings such as ‘an account was able to perform the action’ are often more informative than ’employee X caused the incident’. Where appropriate, give those involved the opportunity to correct factual inaccuracies or missing context.

Individual liability may be necessary in the event of intentional harmful conduct, deliberate sabotage, deception or serious and culpable disregard of a clear risk. Even then, the judgment must follow from facts, hearing both sides, knowable rules and a proportionate response.

The effect of an action is not enough to establish culpability. A small mistake can accidentally cause major damage, while reckless behavior sometimes ends without damage. A Just Culture therefore assesses the behavior and context, not just luck or bad luck in the outcome.

A well-applied Just Culture can increase the willingness to report errors, risks and near-incidents. This allows an organization to gain insight into weak signals sooner, recognize recurring patterns and focus measures on causes rather than just on the last person in the chain.

Other possible benefits include increased trust, better conversations about safety, support for committed employees and continuous process improvement. These effects do not arise from the label alone. A recent scoping review of 36 healthcare interventions found such results, but also emphasizes that it is still difficult to determine exactly which components cause which effect. Just Culture is therefore a working method that supports learning, not a guarantee of fewer incidents.

Look at the quality and distribution of reports, the time to feedback, the percentage of completed improvement measures, recurrence of similar events and the perceived fairness of research. Employees must know where the boundaries are and trust that similar cases will be treated similarly.

An increasing number of reports can initially be a good sign: previously hidden information becomes visible. Merely counting reports is therefore insufficient. Also check whether the organization learns from it, supports reporters, tackles structural causes and motivates decisions in an imitable manner.

No. Just Culture was strongly developed in aviation and later applied in healthcare, among other places, because errors can have major consequences and early reporting is vital. The core — being able to report safely, assessing behavior honestly and in context and improving the system — is also useful in information security, software development, public services and other organizations in which people work with complex systems.

The elaboration must suit the organization. A small foundation has different roles, risks and legal obligations than an airline. Therefore, adopt the principles, but create clear reporting routes, powers, behavioral boundaries and guarantees yourself. The recent scoping review of Just Culture in healthcare also shows that the interventions studied vary and that the evidence about successful implementation is still limited.

Psychological safety means that people in a team dare to take interpersonal risks: asking a question, expressing doubt, admitting a mistake or giving a different opinion. Just Culture is more specific about what the organization then does with a report or event: how it investigates, assesses behavior, protects reporters, distributes responsibility and implements improvements.

The concepts reinforce each other, but are not the same. A pleasant team without clear and consistent assessment is not yet Just Culture. Conversely, a good policy document does not work if people do not dare to speak out in practice. Research into psychological safety mentions inclusive leadership, support and a learning orientation as important conditions. See this systematic review.

Managers set clear expectations, respond calmly to bad news and ensure that reports are investigated independently and expertly. They first ask what happened and what circumstances played a role before drawing conclusions about people. They also free up time, people and budget for improvement measures and provide feedback on what has been done with reports.

Their own actions must also be able to be investigated. If only executive employees are addressed and choices about workload, resources or unclear goals remain out of the picture, the culture is not fair. The AHRQ Guide to System-Based Incident Investigation emphasizes both leadership support and fact-finding rather than blame-finding.

Employees report relevant errors, near-incidents, unsafe conditions and doubts as timely and factually as possible. They participate in research, also share information that may be uncomfortable and help make improvements useful for daily practice. They approach colleagues respectfully and ask for help when knowledge, time or resources are insufficient.

Just Culture demands neither perfection nor heroism. An employee remains responsible for acting carefully within his role, but the organization remains responsible for a workable system, appropriate training and realistic conditions. Responsibility is therefore shared, not shifted.

First, people and systems are secured and receipt of the report is confirmed. An authorized person then determines who will handle the report, what information is needed and what confidentiality can be provided. The research reconstructs the event, involves the relevant people and looks at technical, human and organizational factors.

Findings and measures are then recorded, those involved receive appropriate feedback and it is monitored whether the measures have actually been implemented and are working. A report without visible follow-up damages trust. Research into incident reporting systems warns that collection alone is insufficient; it is precisely improvement actions and a closed learning cycle that determine the value. See this systematic review.

The investigation begins with a timeline and verifiable facts, not with a suspected culprit. Researchers speak to those involved respectfully, test various statements and examine procedures, training, tools, workload, communication, design choices and previous signals. What remains uncertain is also recorded.

Anyone who is personally involved or has a conflict of interest should not decide the outcome alone. Persons involved must be able to explain the relevant facts and have factual inaccuracies corrected. The measure chosen must be appropriate to the conduct and circumstances and comparable cases must be treated similarly. Urgent security measures may be necessary in the meantime, but should not be presented as a disguised punishment.

The organization determines in advance who assesses behavior, according to which criteria and with what possibility of contradiction or reconsideration. Depending on the severity, a manager, safety officer, HR, subject matter expert, employee representation or an independent committee may be involved. Legal questions belong to someone with appropriate expertise.

The assessors not only look at the outcome, but at foreseeability, intention, knowledge, training, available alternatives and the circumstances at the time of action. A serious outcome does not in itself prove reckless behavior; a good outcome does not make consciously dangerous behavior acceptable.

Do not treat doubt as evidence against the person concerned. Gather additional facts, have someone with expert knowledge look at the real options for action and test whether others could have made a similar choice under the same circumstances. Distinguish between what is visible afterwards and what the person could reasonably have known at the time.

Record the trade-off and remaining uncertainty. A drastic personnel measure requires a more rigorous and independent process, with a hearing and an opportunity for reconsideration. In addition, resolve system weaknesses immediately; disagreement about individual accountability is no reason for a demonstrable safety problem to exist.

Confidential reporting means that the identity is only known to people who need it for a careful process. Anonymous reporting means that the recipient does not know the identity. Confidentiality allows further questions and personal feedback; anonymity can lower the threshold if someone fears reprisals or conflicts of interest.

Offer both routes where appropriate and explain honestly in advance what can and cannot be protected. Complete anonymity cannot always be guaranteed technically or legally, and details of an event can indirectly make someone recognizable. Therefore, do not collect more personal data than necessary and limit access and retention periods. European aviation rules mention shielding and removing identifying data as ways to support trust in reporting systems. See the EASA explanation to Regulation 376/2014.

Just Culture and whistleblower protection have a related goal: people should be able to report serious problems without being unfairly disadvantaged. However, they are legally and practically not the same. An internal Just Culture agreement can never replace legal rights, an external reporting channel or protection against retaliation.

Make sure that employees, contractors and volunteers know which channel corresponds to which report and where they can get independent advice. Don’t treat a report as a loyalty issue or try to contractually block a legally permitted external channel. The precise protection depends on the applicable law. The EU Whistleblower Directive includes rules on confidential channels, follow-up and protection against retaliation.

No. Obligations to report an incident, data breach, suspicion of a criminal offense or other occurrence continue to apply. A supervisor, judge or authorized employer also retains their legal role. Just Culture does not stipulate that information must always remain secret and does not grant immunity.

However, Just Culture does require clear, proportionate and consistent procedures: separate learning from disciplinary decision-making where possible, limit access to reporting information and explain when reporting may be mandatory. Tailor the approach to employment law, privacy law, whistleblowing rules, sector rules and existing employee participation. If in doubt, have the specific situation legally assessed.

First map out how people are reporting now, where there is fear or uncertainty and how previous cases have been treated. Then draw up simple rules together with employees and relevant representatives: what do you report, through which channel, who sees the information, how the investigation takes place, where is the behavioral limit and how can someone have a decision reconsidered.

Train managers and researchers with realistic examples. Practice the process, handle the first reports visibly carefully and publish anonymized learning points and progress. Measure trust and follow-up and adjust the process. Better to start small and complete than with a large program without capacity. EASA advises organizations to include clear Just Culture processes in their safety policies and to involve employee representatives. See the EASA Guidance for Reporting Systems.

Common mistakes include: equating Just Culture with never speaking up, setting boundaries only after an incident, confusing the seriousness of the outcome with the culpability of behavior, examining only the last human action and treating similar cases differently. Wide spread of names, leaks of reporting information and a manager who is at the same time directly involved, researcher and decision maker also damage trust.

Another pitfall is asking for reports but not providing feedback or improvements. The reporter then bears the risk while the organization does not fulfill the learning promise. The remedy is verifiable: clear roles, protection of information, timely feedback, visible improvement actions and periodic testing for consistency.

A recovery-oriented Just Culture not only looks at rules, causes and future prevention, but also at the damage that people and relationships have experienced as a result of an event and the response to it. Questions include: who has been affected, what do they need, who has a duty to restore something and how can trust be rebuilt responsibly?

This can lead to recognition, explanation, practical help, restoration of work agreements or a guided conversation. Participation must be careful and appropriate; recovery should not become a means of pressure to enforce forgiveness, silence or renunciation of rights. The scientific literature on restorative Just Culture is growing, but the 2026 scoping review concludes that the evidence on interventions and successful implementation is still limited.

Ask separately what those directly affected, reporters and other involved parties need. Think of factual information, a permanent contact person, rest or adapted tasks, peer support and access to professional help. Explain what the research can and cannot do and when feedback will be provided. Avoid speculation and protect personal data.

Support is not a judgment of guilt and should not depend on subsequent behavior. At the same time, a temporary safety measure may be necessary, for example extra supervision or another task. Justify such a measure, limit it to what is necessary and reassess it as soon as more facts are known.

In a near miss, something went wrong or danger arose, but serious damage was not caused by chance, timely intervention or an extra layer of security. It is then that an organization can learn without anyone having to bear the full consequences first. Recurring detours, unclear instructions and minor deviations can also be early signals of a system problem.

Therefore, don’t just ask “what went wrong?”, but also “what made it go well?” and “which barrier worked?”. Make reporting easy and provide feedback. A systematic review of near misses in healthcare found that leadership support, simple reporting routes, knowledge and a non-punitive response influence reporting behavior. See the review on PubMed.

Do not limit Just Culture to employees with a permanent contract. Suppliers, contractors, researchers, interns and volunteers can be the first to see a vulnerability, error or unsafe situation. Give them an understandable reporting route, explain what protection applies and make it clear in agreements who will investigate and provide feedback.

The organization cannot unilaterally control all employment law or contractual consequences at another party. Therefore, agree in advance how information will be protected, when it will be shared and how retaliation or conflicts of interest will be prevented. In addition to employees, European aviation rules also refer to hired personnel; the EU whistleblowing rules may also include, within their scope, volunteers, self-employed persons and contractors.

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?.

CVSS 4.0 provides an open, vendor-neutral method to capture the technical characteristics and severity of a vulnerability. The vector also shows which values ​​and assumptions led to the score. This makes an assessment more transferable and verifiable than just the label ‘high’ or ‘critical’.

MIAUW uses this common measurement language to report the severity and substantiation of findings in an imitable manner. MIAUW does not automatically determine whether a vulnerability applies and does not prescribe a recovery decision. According to the official specification of FIRST, CVSS is an input to risk analysis, not the complete risk analysis.

No. CVSS describes the technical severity of a vulnerability. An organizational risk also includes, for example, the chance of misuse, the value and function of the system, people affected, legal obligations, possible damage and existing control measures.

FIRST therefore calls CVSS an input for the risk analysis. Factors such as financial damage, reputational damage, the number of affected customers and legal requirements are covered by expressly outside CVSS. An organization weighs these factors in its own risk management.

Yes. CVSS 4.0 explicitly includes context. Threat Metrics describe the current maturity of abuse. Environmental Metrics process the concrete deployment environment, including existing security measures, actual accessibility, the required importance of confidentiality, integrity and availability, changed technical characteristics and possible consequences for human safety.

Supplemental Metrics add further context such as safety, recovery, automation, and recovery effort. They do not change the CVSS number, but according to FIRST’s CVSS 4.0 FAQ they can influence the local priority.

A publicly published CVSS-B usually contains only the Base Metrics. That is not the same as saying that CVSS has no context: the customer completes Threat and Environmental Metrics for his own situation and thus receives a CVSS-BTE. FIRST recommends this enrichment for a more meaningful result in your own environment.

The basic technical score can be the same, but the local CVSS-BTE score does not have to be. An isolated test environment, an internal workstation, a public identity service and a safety-critical device may differ in accessibility, measures, required protection and consequences for other systems or people.

CVSS 4.0 can capture such differences with Threat and Environmental Metrics. Human safety can also factor directly into the score within the Environmental Metrics. Additional context can also influence the local ranking without changing the number. An internal system does not automatically receive a lower score: every adjustment must follow demonstrable properties of the actual environment. See the metric groups and assessment rules of FIRST.

Yes. A scanner hit or corresponding version number does not prove that the vulnerable code is present, accessible or executable. Therefore, first check the component and version used, configuration, call route and any measures. Source code research, an SBOM, VEX, configuration analysis and dynamic testing can provide appropriate evidence for this.

If the product appears not to be affected, document this non-applicability with evidence. Don’t artificially give a low CVSS score to a vulnerability that doesn’t apply. FIRST also describes in the CVSS 4.0 FAQ that a supplier should reassess the score for the concrete product and can use VEX to communicate applicability.

A uniform method gives suppliers, researchers and buyers the same concepts and a machine-readable vector. This allows them to exchange assessments, check assumptions and refine the score for their own environment. Research on vulnerability data shows that inconsistent severity ratings can greatly reduce the quality of further prioritization (Croft, Babar and Li, 2022).

That advantage does not mean that every organization must use the same recovery sequence. The meaningful agreement is: standardize the yardstick, not the decision. Local threat, system context, policy and risk acceptance remain decisive.

Not in the sense of an empirical model that predicts the likelihood of abuse or the expected damage. CVSS is a standardized measurement convention based on technical definitions and expert opinions. For version 4.0, millions of possible vectors have been grouped and ranked by experts; FIRST publishes this method in the user manual.

There is testing, but it is limited. NIST examined the CVSS 3 formula against reviews from the designers. That supports the internal operation of that formula, not the prediction of incidents or damage and not automatically version 4.0. Research also finds differences between human raters. CVSS is therefore useful as a transparent, shared measurement method, not as a scientific certainty.

No. A high CVSS score means that the technical consequences and conditions are severe according to the chosen vector. There is not a calibrated probability that the vulnerability will be exploited within a certain period of time. Research shows that prioritizing solely on CVSS thresholds can be ineffective (Jacobs et al., 2020).

CVSS 4.0 can include current exploit maturity in the Threat Metrics. For example, EPSS can be used for a probability estimate; confirmed attacks and proprietary threat information are also relevant. These sources also do not replace local risk assessment.

No. Policy determines, among other things, the risk appetite, system classes, deadlines, exceptions, persons responsible and conditions for risk acceptance. CVSS can consistently record technical severity, current threat and environmental factors, but does not make an administrative decision.

In risk handling, the organization combines that information with applicability, business impact, security, privacy, legal obligations and available measures. She then decides, for example, to restore, limit, avoid, transfer or accept with motivation. The score and vector provide evidence for that decision; they do not replace the policy, decision or stated rationale.

A useful order is:

1. verify that the vulnerability applies to the product;
2. check the CVSS base score and vector for that product;
3. add current threat information and actual environmental factors;
4. include additional context, such as safety, recoverability and legal obligations;
5. apply your own policy for priority, treatment and risk acceptance;
6. record the decision and substantiation.

This does not create an automatic repair list, but a decision that can be followed. FIRST recommends using Threat and Environmental Metrics for a more meaningful result and calls the outcome an input for your own vulnerability and risk handling.

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.

Are you using Homebrew? Then execute these two commands. The first points Homebrew to our own forge, the second installs OciDeck:

brew tap librekat/ocideck https://pawprint.vigilis.online/LibreKAT/homebrew-ocideck.git
brew install --cask librekat/ocideck/ocideck

The address line is really part of it. If you leave that out, Homebrew will search GitHub and find nothing.

This is the canonical route: both the recipe and the app come from our own forge. If the forge is temporarily unavailable, the GitHub mirror is the backup copy. This is done in one command, because the short form of Homebrew by definition points to GitHub:

brew install --cask brennodewinter/ocideck/ocideck

However you install, Homebrew pulls the release directly from our own forge and checks the checksum automatically. The app is signed with an Apple Developer ID and notarized by Apple, so it then opens with a simple double-click.

To update to a later version, run:

brew upgrade --cask ocideck

The cask is only a pointer to that same signed, notarised release; Homebrew does not host the app itself and no extra intermediary is involved. Homebrew Cask exists only for macOS — on Windows and Linux you download OciDeck directly.

Prefer not to use Homebrew? Then download OciDeck directly from the OciDeck page. That page also explains, per platform, how to open and verify the download.

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.