Effects of software errors: Legal and ethical liability in case of failures or errors

Need testing support? Check our Quality Assurance services.

Let’s discuss your project

“Write tests with different granularity. The more high-level you get, the fewer tests you should have.”

— Mike Cohn, Succeeding with Agile | Source

Have questions or need support? Contact us – our experts are happy to help.

In today’s world, software controls almost every aspect of our lives - from critical medical systems to banking infrastructure to everyday applications. However, where there is code, there can be errors. When a system fails, a fundamental question arises: who is responsible for the consequences? This article examines the complex issue of liability for software bugs, pointing to the legal and ethical aspects of a problem that is becoming increasingly pressing in the digital age.

What is liability for the effects of software and who is charged?

Software consequences liability is the legal and ethical obligation to bear the consequences resulting from errors, failures or malfunctions of information systems. It covers both direct tangible and intangible damages that may arise as a result of software malfunctions. In practice, determining the responsible party is often complicated by the complex ecosystem of software development and distribution.

The chain of responsibility for software includes manufacturers, individual developers, implementation companies, cloud service providers and even end users. Each of these entities may bear partial responsibility, depending on the specifics of the case and the nature of the error. For example, if an accounting system fails during fiscal year-end closing, causing financial losses, the responsibility may lie with both the software manufacturer and the implementation company that failed to conduct proper testing.

It’s worth noting that software liability extends far beyond the traditional boundaries of the IT industry. In the Internet of Things (IoT) era, when software is embedded in physical products, device manufacturers also face code liability challenges. Imagine a situation in which a flaw in the software of a smart thermostat leads to an overheating heating system and a fire, in which case legal liability could affect both the manufacturer of the device and the developer of the control software.

The issue is even more complex in the case of solutions based on artificial intelligence or autonomous systems, where the definition of “error” becomes unclear and the predictability of system behavior is limited. Establishing responsibility for incorrect decisions of machine learning algorithms is one of the most serious challenges of modern new technology law.

Key players in the software liability chai

Software manufacturers - responsible for the basic quality and security of the product
Programmers - are responsible for the quality of the code they write
Implementation companies - responsible for proper implementation and configuratio
Cloud service providers - bear responsibility for infrastructure and availability
End users - are responsible for proper use in accordance with the terms of the license

How do we define a “bug” in software in a legal and ethical context?

Defining the concept of “bug” in software is not a trivial task and is fundamental to determining legal liability. In the legal context, a software bug is most often defined as a discrepancy between the actual operation of a program and its specifications, documentation or the user’s reasonable expectations. However, this definition opens the door to broad interpretation - what exactly constitutes “reasonable expectations”?

From the perspective of the Civil Code, a software defect can be treated as a physical defect in a product that diminishes its value or usefulness in view of the purpose of the contract or the purpose resulting from the circumstances or purpose of the thing. In consumer law, a software defect is often interpreted through the prism of non-conformity of goods with the contract, where the product should have features that the consumer can reasonably expect based on the seller’s representations.

The ethical definition of an error goes beyond the purely technical dimension to include aspects related to the potential harm that software can cause to users or society. In this context, a bug can also be a function that technically works according to the specification, but whose consequences are harmful - for example, an algorithm that acts discriminatorily against certain social groups.

It is also worth distinguishing between different categories of bugs, which can have different legal implications. “Bugs” are usually unintentional technical glitches, while “security vulnerabilities” pose a more serious threat allowing unauthorized access to a system. “Design bugs” can result from incorrect assumptions about how a program should be used, while “implementation bugs” occur at the coding stage. Each of these categories can generate a different level of legal liability.

For example, in the case of critical medical software, even a minor glitch may be interpreted as a serious error from a legal perspective if it threatens patient safety. On the other hand, a similar glitch in a photo-editing application may be considered a minor inconvenience, not justifying a legal claim.

Software error categories

Type of error	Characteristics	Legal implications
Bug	Unintentional technical fault	Dependent on the impact and criticality of the system
Security gap	Defect that allows unauthorized access	Potential liability for data breaches
Design error	Incorrect assumptions about use	May indicate negligence at the planning stage
Implementation error	Incorrect implementation of assumptions	Responsibility of the programmer or development team

What are the most common causes of software errors?

Software errors do not arise by accident - they are the result of a complex mix of circumstances and factors, understanding of which is key to properly assessing legal liability. The most common causes of software errors can be divided into several major categories, ranging from organizational problems to human factors to technical challenges.

Time pressure and insufficient budget are factors that often lead to errors. When development teams work under deadline pressure, code quality can suffer. Similarly, when financial resources are limited, companies may choose to cut back on quality assurance processes, which directly translates into an increased risk of bugs. From a legal perspective, deliberately reducing the testing budget for critical systems can be interpreted as negligence.

Another important factor is insufficient communication between project stakeholders. When business requirements are not accurately communicated to the technical team, or when developers do not fully understand the business domain, space is created for misunderstandings that result in errors. In this context, the responsibility can lie with both the development team and the business side, which failed to ensure the quality of the requirements.

The complexity of modern software systems is another source of potential errors. Today’s software often consists of millions of lines of code and integrates dozens of external libraries and services. In such a complex environment, even experienced programmers can have difficulty predicting all possible interactions between components. From a legal perspective, the key question becomes whether the team has taken adequate precautions with best practices for managing complexity.

Outdated technical documentation and incomplete testing are factors that often contribute to the perpetuation of bugs. When developers work with outdated documentation or when test coverage is insufficient, the risk of introducing new bugs increases significantly. In the context of legal liability, negligence in the areas of documentation and testing can be interpreted as a lack of due diligence.

Main causes of software errors vs. legal implications

Time pressure and insufficient budget - may indicate neglect of quality assurance duty
Insufficient communication between stakeholders - responsibility spread **betwee ** technical and business team
Complexity of information systems - requires proving the use of appropriate complexity management methodologies
Outdated documentation and incomplete tests - potential evidence of lack of due diligence

Who specifically is responsible for errors: the manufacturer, the programmer, the supplier, or the user?

Responsibility for software errors rarely rests with a single entity. In practice, it is distributed among various links in the production and distribution chain, and its allocation depends on the specifics of the case, the nature of the error and the applicable laws. Analysis of this issue requires consideration of the role of each participant in this ecosystem.

The software manufacturer, or the company that puts the product on the market, usually bears primary responsibility for its quality and safety. Under Polish and EU law, the manufacturer is liable for a dangerous product on a strict liability basis, which means that the injured party does not have to prove the manufacturer’s fault, but only the fact of the defect, the occurrence of the damage and the causal link between the two. For example, if a financial system contains a fundamental design flaw leading to a loss of customer funds, its manufacturer will be held liable in the first instance.

Individual programmers are most often not directly liable to end users when acting as employees or subcontractors. Their liability is usually limited to their relationship with their employer or principal, unless gross negligence or willful misconduct can be attributed to them. It is worth noting, however, that in the case of independent developers publishing their own applications, legal liability rests directly with them as producers.

Software suppliers, integrators and implementers bear responsibility in terms of proper implementation, configuration and integration of systems. If the software malfunctions due to misconfiguration or suboptimal integration with other systems, the responsibility may lie with the implementation company. In B2B relationships, the extent of this responsibility is often detailed in SLAs (Service Level Agreements).

Software users also bear some responsibility, especially when they use the program contrary to its intended use, documentation or license terms. A user’s liability increases when he or she ignores security updates, uses illegal copies of the software or knowingly bypasses security features. In court practice, the user’s contribution to the damage can significantly affect the extent of the other parties’ liability.

It is worth noting that responsibility for embedded software in physical devices (embedded software) is often spread between the device manufacturer and the software provider. In the case of autonomous systems using artificial intelligence, where decisions are made by learning algorithms, the issue of liability becomes even more complex and is the subject of intense legislative work at the EU level.

Division of responsibility for software errors

Entity	Responsibilities	Typical limitations
Manufacturer	Overall product quality and safety	Exclusions in the license, cases of force majeure
Programmer	Code quality (mainly towards the employer)	Limited liability to end users
Supplier/Integrator	Proper implementation and configuratio	The scope as defined in the SLA
User	Compatible use	Contribution to injury

How do you distinguish between contractual and tort liability in the case of defective software?

In the context of defective software, the distinction between contractual and tort liability is crucial, as it determines both the legal basis for claims and their scope and the compensation that can be obtained. These two regimes of liability, although they may be intertwined, are based on different principles and premises.

Contractual liability arises from non-performance or improper performance of a contractual obligation. In the case of software, this can apply if the delivered solution does not meet the agreed parameters, functionality or security level specified in the contract. For example, if a development company has agreed to create a CRM system with certain functions, and the delivered solution fails to implement these functions or malfunctions, we have contractual liability.

Within the framework of contractual liability, precise contractual provisions, including requirements specifications, quality guarantees and acceptance and testing procedures, play a key role. The parties have a great deal of freedom in shaping the scope of mutual obligations and responsibilities, being able to introduce clauses that limit or expand standard liability. In practice, IT contracts often include provisions for contractual penalties for failure to meet quality parameters or deadlines.

Tort liability, on the other hand, arises regardless of the existing contractual relationship and arises from a breach of the general duty not to cause harm to others. In the context of software, tort liability may apply when faulty software causes harm to third parties who are not parties to the contract. For example, if an error in a banking application leads to the disclosure of customers’ personal data, the bank may be liable in tort to the injured customers.

It is worth noting that in many cases the event causing the damage may simultaneously constitute a breach of contract and a tort, leading to the so-called concurrence of claims. In Polish civil law, the injured party in such a situation has the opportunity to choose the regime of liability on which to base his claims. This choice is of practical importance, as it affects the principles of liability, the length of the statute of limitations and the extent of compensation that can be obtained.

From an evidentiary perspective, contractual liability is often easier to prove, as it is based on specific contractual provisions. In the case of tort liability, the injured party must prove not only the fact of damage, but also the culpability of the perpetrator and the causal link between the act or omission and the damage, which in the case of complex IT systems can be a significant challenge.

Comparison of contract and tort liability in IT

Aspect	Contractual liability	Tort liability
Basis	Non-performance of contract	Violation of the general prohibition on causing harm
Who can claim	Parties to the contract	Any victim
Command	Breach of contractual provisions	Fault, damage, causatio
Restrictions	Possible in the contract	Limited options for exclusion
Statute of limitations	Usually shorter (2 years)	Longer (3-10 years)

What legal mechanisms in Poland and around the world regulate liability for software errors?

Liability for software errors is governed by a complex web of laws that vary from jurisdiction to jurisdiction and evolve with technological advances. In Poland and the European Union, the legal framework includes both general civil law and specific regulations for product liability, consumer protection and digital services.

In the Polish legal system, the fundamental basis for liability for defective software is the Civil Code, in particular the provisions on warranty for defects, contractual liability and tort liability. In B2C (business-to-consumer) relations, the provisions of the Consumer Rights Act, which grant software purchasers a number of rights, including the right to withdraw from the contract within 14 days of purchasing digital content, are important. It is worth noting that the Polish legislator has transposed into the national legal order the EU Directive 2019/770 on digital content, which introduces the harmonization of rules on compliance of digital content with the contract.

At the EU level, the Defective Products Liability Directive, which establishes the principle of strict liability of the manufacturer for damage caused by a dangerous product, is of key importance. Although the directive was originally created with physical products in mind, the evolution of case law and legislative changes are moving towards including software in its scope, especially when it is an integral part of a physical device or when it is a stand-alone product.

In the United States, the legal system is based more on court precedents and varies from state to state. There, the Uniform Commercial Code (UCC) provisions governing commercial transactions, including the sale of software as a commodity, play a key role. US courts have also developed the doctrine of product liability, which can be applied to software under certain circumstances. It is worth noting that in the U.S., technology companies have relatively more freedom to limit their liability through licensing agreements.

A particular challenge for current legal mechanisms is the regulation of liability for autonomous systems based on artificial intelligence. The European Commission is working on a dedicated legal framework to define liability rules for damages caused by AI systems. Proposed solutions are moving in the direction of establishing requirements for algorithm transparency, oversight and certification mechanisms, and specific liability rules for high-risk systems.

The issue of jurisdiction and applicable law is also important in the context of cross-border digital services. Companies offering software on a global scale have to take into account differences in the legal regulations of individual countries, which poses a significant compliance challenge. An attempt to harmonize certain aspects in this regard is the EU Digital Services Act, which introduces uniform liability rules for intermediary service providers, including online platforms.

Key legal mechanisms governing software liability

Poland: Civil Code (warranty, contractual and tort liability), Consumer Rights Act
EU: Digital Content Directive, Defective Products Liability Directive, Digital Services Regulatio
USA: Uniform Commercial Code, product liability doctrine, case law
Global: United Nations Convention on Contracts for the International Sale of Goods (CISG)

What is the significance of a software license in terms of software liability?

The software license is the legal foundation of the relationship between the manufacturer and the user, and is crucial in defining the scope of liability for possible errors. A license agreement is not just a formal requirement - it is a comprehensive legal document that defines the rights, obligations and limitations of both parties, including liability issues related to malfunctioning software.

In business practice, there are several dominant licensing models, each of which approaches the issue of producer liability differently. Traditional commercial licenses usually contain extensive clauses limiting the vendor’s liability to the minimum required by applicable regulations. Open source licenses, on the other hand, most often contain clauses that completely exclude authors’ liability for any damages resulting from the use of the software, which is justified by the non-commercial nature of these solutions.

It is worth noting the growing popularity of the SaaS (Software as a Service) model, in which access to software is offered as a service instead of selling licenses. In this model, accountability is governed by service-level agreements (SLAs), which specify guaranteed levels of availability, performance and error-repair procedures. SLAs often include compensation mechanisms such as service credits in the event that promised performance is not met.

From a legal perspective, the possibility of limiting liability in software licenses is not unlimited. In B2C (business-to-consumer) relations, consumer protection laws in many jurisdictions consider prohibited provisions that completely exclude the seller’s liability for product defects. In Poland, such limitations arise, among others, from Article 385³ of the Civil Code, which contains a catalog of prohibited contractual clauses.

Even in B2B (business-to-business) relationships, where parties have more freedom to shape contractual relationships, there are limits to the possibility of limiting liability. In most jurisdictions, it is not possible to effectively exclude liability for damage caused intentionally or through gross negligence. Similarly, clauses limiting liability for personal injury are usually considered invalid.

The software license also serves an important informational function - it specifies the program’s permitted use cases, system requirements and known limitations, which can be important in assessing whether the user has followed the manufacturer’s guidelines. For example, if the license explicitly prohibits the use of the software on safety-critical systems, and the user ignores this stipulation, this could significantly affect the issue of liability in the event of a failure.

Liability clauses in different types of licenses

License type	Typical liability provisions.	Legal Effectiveness
Commercial	Limitation of liability to the price paid	Dependent on relationship (B2B/B2C) and jurisdictio
Open Source (e.g., GPL, MIT).	Total exclusion of liability	Limited in consumer relations
SaaS / Service	Availability and performance guarantees specified in the SLA	High in B2B relations
Enterprise	Individually negotiated terms and guarantees	Depends on the negotiating power of the parties

Can and how can liability for errors in licensing agreements be limited or excluded?

Limiting or excluding liability for software errors is one of the most essential elements of technology companies’ legal strategy. However, the options in this regard vary depending on the nature of the business relationship, the jurisdiction and the specifics of the product. Understanding the available mechanisms and their limits is crucial for both software providers and purchasers.

In the context of business-to-business (B2B) relationships, parties have a relatively high degree of freedom to shape the scope of contractual liability. Popular mechanisms include clauses limiting financial liability to a certain amount (usually equal to the contract value or a multiple thereof), excluding liability for indirect damages and lost profits, and establishing an exhaustive catalog of remedies available to the customer. For example, a contract may stipulate that the only remedy in the event of an error is to improve the software or refund the price paid.

The use of “best effort” clauses, which modify the standard of due diligence required of a software supplier, is also common in business practice. Rather than guaranteeing a specific result, the supplier merely undertakes to use its best efforts to ensure that the system works properly. This design significantly reduces legal risk, especially in the context of complex IT systems, where it may be virtually impossible to achieve 100% reliability.

In B2C (business-to-consumer) relationships, the possibilities for limiting liability are much narrower due to the protection afforded to consumers by law. In the European Union, clauses that completely exclude the software manufacturer’s liability for its compliance with the contract are considered prohibited contractual provisions. Similarly, it is not possible to effectively exclude a consumer’s rights under a warranty for defects, although they can be limited to some extent.

Significant limitations on the possibility of indemnification also exist in the case of personal injury - in virtually all jurisdictions, clauses excluding liability for injury to health or life are considered invalid. This is particularly relevant for software that controls medical devices, autonomous vehicles or other systems whose failure can lead to a risk to health or life.

An interesting case is open source licenses, which typically contain wording that completely excludes the liability of creators. The effectiveness of such clauses is judged differently in different jurisdictions, and they may be challenged in the consumer context. However, the community and non-commercial nature of many open source projects is often recognized as a circumstance justifying a more far-reaching limitation of liability.

From a legal strategy perspective, a comprehensive approach to limiting liability includes not only appropriate contractual clauses, but also clear product documentation, clear warnings about limitations and known problems, and detailed instructions on proper use. These elements can significantly affect the assessment of whether the manufacturer has exercised due diligence in preventing potential damage.

Strategies for limiting liability in IT contracts

Financial cap - determining the maximum amount of compensation (usually the equivalent of the contract)
Exclusion of indirect damages - no liability for lost profits and business opportunities
Limited catalog of claims - clear identification of the only remedies available
Best efforts clauses - modification of the due diligence standard
Error reporting requirements - procedures and deadlines for notification of defects
Exclusion of implied warranties - precise definition of the scope of the warranty

How to document the software development process to reduce legal risks?

Proper documentation of the software development process is a key element of a legal risk management strategy for development companies. It is not only a tool to improve the quality of the product, but also a potential proof of due diligence in case of legal disputes. Well-maintained documentation can significantly strengthen a software developer’s litigation position, proving that it has made every effort to ensure the safety and reliability of its product.

Particularly important is the documentation of software requirements and specifications. Precise specification of functionality, performance parameters, security requirements and acceptable use cases provides a benchmark for assessing whether the product performs as expected. In the event of a legal dispute, a clear and agreed-upon specification with the customer allows an objective assessment of whether the software meets the agreed parameters. It is worthwhile to ensure that the specification is formally approved by the customer, which minimizes the risk of later misunderstandings.

Design documentation, including system architecture, component diagrams and interface descriptions, provides evidence of a thoughtful approach to software construction. In the event of a system failure, being able to demonstrate that the architecture was designed in accordance with industry best practices can be a key argument against allegations of negligence. Evidence of formal design reviews with experienced architects is particularly valuable.

Equally important is the documentation of testing processes. Unit, integration, system and security test reports help prove that the software has undergone rigorous verification before deployment. In the legal context, security tests, including penetration tests, are of particular importance, as they can confirm that the manufacturer actively sought out and eliminated potential vulnerabilities. For critical systems, it is recommended that full test documentation be maintained, including test plans, test cases, performance reports and corrective actions.

In the software development process, it is also worth documenting all design decisions, especially those involving trade-offs between functionality, security, performance and cost. In the event of a legal dispute, the ability to explain and justify such decisions can be crucial to demonstrating that any product limitations were a conscious and legitimate choice and not the result of negligence. Documentation of such decisions should include an analysis of alternatives, selection criteria and potential risks.

From a legal risk management perspective, documentation of known software problems and limitations deserves special attention. Providing the customer with clear information about identified limitations, potential risks and recommended remedies can significantly reduce the manufacturer’s liability. In many jurisdictions, the informed acceptance of risks by a customer who has been properly informed of them can be an effective line of defense in the event of a dispute.

Key documentation to reduce legal risk

Type of documentatio	Legal significance	Recommended practices
Requirements specification	Definition of agreed product features	Formal customer approval
Project documentatio	Proof of best practices	Regular reviews of the architecture
Test reports	Confirmation of quality verification	Maintaining a complete test history
Risk analysis	Proof of conscious threat management	Systematic update
Documentation of known limitations	Protection against unreasonable expectations	Clear communication with the customer
History of changes and amendments	Proof of active product maintenance	Detailed description of all changes

How does software testing minimize liability for errors?

Software testing is a fundamental part of risk management and legal liability minimization strategies for development companies. Comprehensive and properly documented testing processes not only improve product quality, but also create a solid line of defense in the event of potential claims related to software defects. The importance of testing in the legal context goes far beyond the technical aspect and provides evidence of due diligence by the manufacturer.

Unit testing, i.e. verifying the correctness of individual program components, forms the first line of defense against errors. From a legal perspective, a high level of code coverage by unit testing can demonstrate a systematic approach to quality assurance. In the event of a dispute, a software developer can present unit test reports as evidence that individual system components have been individually verified and potential problems in their functionality have been detected and fixed early.

Integration and system tests, which verify the interaction of components and the operation of the entire system, are particularly important in the context of complex IT solutions. They can provide key evidence that the manufacturer has anticipated and tested a variety of usage scenarios and interactions between components. In the event of a system failure, the ability to show that a specific scenario was tested but the error occurred under unusual circumstances can significantly reduce the manufacturer’s liability.

From a legal liability perspective, security testing, including penetration testing and code analysis for security vulnerabilities, is of particular value. With data breach incidents on the rise, a manufacturer that can prove systematic security testing of its product has a stronger position in the event of a potential attack. It is worth noting that in some sectors, such as banking and health care, regulators require documented security testing.

Performance and load tests can verify system behavior under increased load conditions, which is important for critical services. From a legal perspective, demonstrating that a system has been tested under a load that far exceeds standard operating conditions can argue against charges of inadequate preparation for peak situations.

In addition to technical benefits, test automation also offers significant value from a legal risk management perspective. Automated regression testing, performed with each code change, minimizes the risk of introducing new bugs during software updates. In the event of a dispute, the manufacturer can demonstrate that each version of the product has undergone a rigorous verification process, demonstrating a systematic approach to quality assurance.

Impact of different types of tests on minimizing legal liability

Unit testing: Proof of systematic verification of individual components
Integration testing: Confirmation of verification of interaction between modules
System testing: Verification of compliance with functional requirements
Security testing: Crucial in the context of data protection and privacy
Performance testing: Protection against allegations of unpreparedness for the load
Regression testing: Minimize the risk of introducing new errors with updates

What security and software quality standards should be followed?

Adherence to recognized software security and quality standards is an important part of a legal risk management strategy for technology companies. These standards not only help create better products, but also provide objective measures of due diligence that can be crucial in the event of legal disputes. In the current regulatory environment, compliance with industry standards is increasingly becoming not just a best practice, but even a legal requirement in many sectors.

ISO/IEC 27001 is an international standard that defines requirements for information security management systems (ISMS). While it does not focus directly on the software development process, it provides a comprehensive framework for managing information security risks. From a legal perspective, ISO 27001 certification can provide strong evidence that an organization has a systematic approach to identifying and managing security risks, which can be crucial in terms of liability for data breaches or security incidents.

OWASP (Open Web Application Security Project) provides widely recognized guidelines for web application security, including the famous OWASP Top 10 list, which identifies the most common security threats. While OWASP does not offer formal certification, compliance with its guidelines is often considered a standard of due diligence in the industry. In the event of a security incident, the ability to demonstrate that an application was built with OWASP guidelines in mind can significantly strengthen a vendor’s legal position.

The ISO/IEC 25010 (Systems and software Quality Requirements and Evaluation - SQuaRE) standard defines quality models for software and computer systems. It defines eight quality characteristics, including functionality, reliability, usability and security. Applying this standard to the software development process allows for a systematic approach to evaluating product quality, and in a legal context can help objectively assess whether software meets generally accepted quality standards.

Of key importance for medical software is the IEC 62304 standard, which defines requirements for the life cycle of medical software. Compliance with this standard is often a regulatory requirement for product launch and is an important line of defense in the event of medical software defect claims. The standard imposes stringent risk management, verification and validation requirements that go beyond typical practices in other sectors.

In the context of software development processes, standards such as CMMI (Capability Maturity Model Integration) or ISO/IEC 12207, which define good software engineering practices, are important. CMMI certification at higher levels (4 or 5) can provide strong evidence that an organization has mature and repeatable software development processes, reducing the risk of introducing errors resulting from an unsystematic approach.

When it comes to AI-based solutions, ethical standards and guidelines for the explainability and transparency of algorithms are becoming increasingly important. While there is not yet a universal standard in this regard, adherence to guidelines from organizations such as the IEEE or AI Ethics Guidelines from the European Commission can help demonstrate that an AI system has been built with potential ethical and social risks in mind.

Key industry standards to minimize legal risks

Standard	Application area	Legal significance
ISO/IEC 27001	Information security	Proof of systematic security risk management
OWASP	Web application security	Compliance with recognized industry guidelines
ISO/IEC 25010	Software quality	Objective measures of product quality
IEC 62304	Medical software	Compliance with regulatory requirements
CMMI	Manufacturing processes	Proof of maturity of organizational processes
ISO/IEC 12207	Software lifecycle	A systematic approach to creating and maintaining
PCI DSS	Payment security	Key in the context of financial applications

What are the legal and financial consequences for companies whose software causes damage?

The legal and financial consequences for companies whose software causes damage can be far-reaching and multidimensional, affecting a company’s reputation, market position and financial stability. The extent of these consequences depends on a number of factors, including the nature of the damage, the degree of negligence, the contractual relationship between the parties and the jurisdiction in which the dispute occurs.

Direct financial consequences primarily include the cost of damages awarded to injured parties. In B2B relationships, the amount of damages is often limited by contractual provisions, usually to the value of the contract or a multiple thereof. However, in the case of mass damages affecting many users, the total amount of claims can significantly exceed these limits. In the United States, where class action lawsuits are possible, a single bug in commonly used software can lead to claims totaling millions of dollars.

In the event of a personal data breach, an additional consequence is administrative penalties imposed by supervisory authorities. In the European Union, under the RODO, these penalties can reach 4% of a company’s global a

ual turnover or €20 million, whichever is higher. It is worth noting that not only the data controller, but potentially the processor as well, is subject to the penalty if the software error is due to a failure to meet the security requirements of the RODO.

In addition to direct financial costs, expenses related to crisis management and reputation repair are a serious burden. These include the costs of notifying victims, providing credit monitoring services (in the event of financial data leaks), communication campaigns to rebuild trust, and potential sales declines resulting from reputational damage. Studies indicate that these indirect costs can exceed direct compensation expenses many times over.

In some regulated sectors, such as banking, health care or energy, an additional consequence could be regulatory intervention, leading to the suspension or revocation of a business license. This can occur when a software error leads to a violation of regulatory requirements, such as the capital adequacy of banks or patient safety in medical facilities.

Criminal legal consequences are also an important aspect, especially in cases of gross negligence leading to danger to life or health. Although criminal liability primarily applies to individuals, in some jurisdictions it is possible to hold legal entities criminally liable as well. For example, in the case of a fatal accident caused by faulty autonomous car software, both programmers and executives could potentially face manslaughter charges.

Spectrum of legal and financial consequences for IT companies

**Civil compensatio ** - from individual claims to class action lawsuits
Administrative penalties - particularly severe for RODO violations
Remediation and remediation costs - fixing errors and preventing future incidents
Spending on crisis management - communications, PR, reputation restoratio
Loss of revenue - resulting from loss of confidence and customer chur
Increase in insurance costs - after incident causing damage
Regulatory consequences - potential loss of licenses in regulated industries
Criminal liability - for gross negligence with serious consequences

Is there insurance to protect IT companies from the effects of software errors?

The insurance market for the IT industry is evolving rapidly, offering increasingly specialized products to protect companies from the financial consequences of software errors. These insurances are an important part of a risk management strategy, allowing a portion of the risk to be transferred to the insurer and safeguarding the financial stability of the company in the event of a major incident. The spectrum of available policies is wide, and choosing the right insurance requires careful analysis of the specific risks associated with a company’s operations.

The primary product for IT companies is Professional Indemnity Insurance, which protects against claims arising from errors, omissions or oversights in services provided. The policy typically covers the cost of compensating customers who have suffered financial losses as a result of faulty software, as well as legal defense costs. It is important that the coverage includes specific risks associated with IT operations, such as code errors, faulty implementations or failure to meet performance parameters.

With cyber threats on the rise, cyber insurance (Cyber Insurance) is becoming increasingly important. Unlike traditional liability insurance, it focuses on risks related to data security and cyber incidents. A typical cyber policy covers the costs associated with a data breach, including notification of victims, credit monitoring, cyber investigation costs and regulatory penalties. For companies developing software that processes personal data, this insurance is an important supplement to basic third-party liability protection.

A specific product for the IT sector is Errors and Omissions Insurance (E&O). While conceptually similar to Professional Liability, it is specifically tailored to the technology industry and covers damages resulting from software errors, insufficient testing, system integration problems or failure to deliver on functionality promises. E&O policies also often include coverage for intellectual property infringement claims, which is important in the context of potential patent or copyright disputes.

For companies developing products in the Internet of Things (IoT) or embedded control systems category, Product Liability Insurance is important. It protects against claims resulting from product defects that lead to property or personal damage. In the context of embedded software, this policy can cover damages caused by devices operating under the control of faulty code, for example, when an error in smart home software leads to a fire.

It is worth noting that obtaining comprehensive insurance for IT companies usually requires certain security and quality conditions. Insurers often require the implementation of specific risk management procedures, security certifications (such as ISO 27001) or regular audits. From the company’s perspective, meeting these requirements not only lowers the insurance premium, but also contributes to real improvements in software security and quality.

Main types of insurance for IT companies

Type of insurance	Scope of protection	Relevant aspects
Professional Liability	Financial damage from service errors	Basic protection for any IT company
Cyber Insurance	Costs associated with a data breach	Key when processing personal data
Errors & Omissions	Specific risks of the technology industry	Protection against defective software claims
Product Liability	Personal and material damage caused by the product	Relevant to IoT and embedded systems
Business Interruptio	Loss of revenue due to systems failures	Supplementing basic protection
Intellectual Property	Protection against IP infringement claims	Important in the context of patent litigatio

How does RODO affect liability for errors in software that processes personal data?

The General Data Protection Regulation (GDPR) has introduced fundamental changes in the approach to responsibility for processing personal data, with direct implications for software developers and providers. The regulation has significantly expanded the responsibilities of those involved in data processing, introducing stringent security requirements and heavy penalties for violations. For technology companies, this means that they need to take a comprehensive approach to data protection right from the software design stage.

A fundamental principle introduced by the RODO is the concept of “privacy by design” and “privacy by default,” which requires developers of IT systems to consider the protection of personal data at the design stage and to ensure that, by default, only data that is necessary to achieve a specific purpose is processed. From a legal liability perspective, this means that software errors leading to excessive data collection or lack of adequate safeguards can be interpreted as violations of these fundamental principles.

Article 32 of the RODO requires the implementation of “appropriate technical and organizational measures” to ensure the security of data processing. While the regulation does not define precisely what measures are “appropriate,” it indicates that they should take into account the state of the art, the cost of implementation, and the context and purposes of the processing. In practice, this means that software developers must keep abreast of the latest security standards and regularly update their products when new threats or vulnerabilities emerge.

An important aspect of the RODO from a software liability perspective is the distinction between the role of data controller and processor. A software provider can act in either of these roles, depending on the nature of the services provided. If the company merely provides a data processing tool (e.g., a CRM system installed locally), its responsibility is usually limited to ensuring that the software enables the controller to meet the requirements of the RODO. However, if the provider processes data on behalf of the client (e.g., in a SaaS model), it becomes the processor and has direct responsibility for compliance with the regulation.

The RODO also introduces an obligation to report data protection breaches within 72 hours of detection. For software developers, this means the need to implement incident detection and reporting mechanisms that will enable data controllers to comply with this obligation. The lack of such functionality in systems that process personal data can be interpreted as negligence and lead to contractual liability to clients who have failed to meet their regulatory obligations as a result of this negligence.

Particularly relevant from the perspective of software developers is Article 82 of the RODO, which introduces the principle of joint and several liability of the controller and processor for damages caused by a breach. This means that a person who has suffered damage as a result of a violation of the RODO can seek compensation from both the controller and the processor. In practice, this could lead to a situation where the customer (as administrator) will seek recourse from the software provider (as processor) if the breach was due to an error in the software.

Also worth noting is the requirement to conduct a Data Protection Impact Assessment (DPIA) for high-risk processing operations. While this obligation is formally incumbent on the controller, software vendors often offer tools and methodologies to support the DPIA process. From a legal liability perspective, the provision of inadequate risk assessment tools can contribute to the improper identification of risks and subsequent data protection breaches.

The impact of RODO on the liability of software developers

**Privacy by desig **: Require data protection to be considered at the design stage
Adequate security measures: Need to implement up-to-date security measures
Joint and several liability: the ability to pursue claims against both the administrator and the processor
Obligation to report violations: Need to implement detection and reporting mechanisms
Documentation of compliance: Requiring proof of compliance with RODO rules
DPIA support: Responsibility for providing adequate risk assessment tools

How does the warranty institution protect consumers from software defects?

The institution of warranty for defects is a fundamental mechanism for protecting consumers in the case of defective software, providing them with a number of rights independent of the warranties offered by manufacturers. In the Polish legal system, warranty is regulated by the Civil Code and is of particular importance in the context of software purchased by consumers, where it is an inherent element of the sales contract, which caot be excluded or limited in B2C relations.

The basic premise of warranty is that a seller is liable for physical and legal defects in goods, including software. Physical defect in the context of software includes cases when the program does not have the properties it should have due to the purpose stated in the contract or resulting from the circumstances, when it is not suitable for the purpose the consumer informed the seller of and the seller did not object, or when it was issued in an incomplete state. For example, if a photo-editing application is advertised as having an advanced color-correction function, and this function does not work properly, the consumer can claim a physical defect.

A legal defect, on the other hand, occurs when the software is encumbered by the rights of a third party (e.g., it constitutes copyright infringement) or when the seller has imposed restrictions on the use of the software of which it has not informed the consumer. In practice, the sale of pirated copies of software or products that infringe patents is a classic example of a legal defect, giving rise to a warranty claim.

Under warranty rights, the consumer has the right to demand repair of the software, replacement with a defect-free product, price reduction or cancellation of the contract (if the defect is material). Importantly, it is up to the consumer to choose between these rights, although the seller may offer an alternative solution under certain circumstances. In the context of software, repair usually takes the form of a patch or update that fixes a bug, while replacement involves providing a new, corrected version of the program.

An important aspect of the warranty is the term of the seller’s liability, which for consumers is two years from the delivery of the item. For software, this means that errors discovered within two years of purchase can be the basis for a complaint, even if the manufacturer offers a shorter warranty period. It is also worth noting the presumption that exists in consumer law, according to which a defect discovered within one year of the delivery of the goods is considered to exist at the time of delivery, which significantly facilitates the assertion of claims.

In the case of electronically delivered digital content (e.g., software downloaded from the Internet), provisions implementing Directive 2019/770 on digital content apply, further strengthening consumer protection. Among other things, these regulations introduce an expanded definition of conformity with the contract and specific consumer rights in the event of non-conformity of digital content with the contract, including the right to bring the content into conformity with the contract at no cost and the right to compensation for damages caused by non-conformity.

Key aspects of software defect warranty

Aspect	Characteristics	Importance to the consumer
Physical defect	Lack of features that software should have	Basis for claiming functionality
Legal defect	Encumbrance of third-party rights, such as violation of licenses	Protection against illegal software
Entitlements of the consumer	Repair, replacement, price reduction, withdrawal	Freedom of choice of remedy
Warranty term	2 years from the release of the item	Long-term protection independent of warranty
Presumptio	The defect discovered within one year of issuance existed at the time of issuance	Evidence facilitation for the consumer

How to prove the causal link between the software defect and the resulting damage?

Proving a causal link between a software defect and the resulting damage is one of the biggest challenges in disputes over liability for errors in information systems. The complexity of modern systems, their interactions with other components, and the multitude of factors that can affect the functioning of software mean that proving a direct link between a specific error and damage requires a systematic approach and often specialized knowledge.

In the Polish legal system, causation is understood in accordance with the theory of adequate causation, as expressed in Article 361 § 1 of the Civil Code. According to this theory, the obligor of damages is liable only for the normal consequences of his act or omission. In the context of software, this means that the manufacturer is liable for damages that are the typical, foreseeable result of an error in its product, but not for all possible consequences, especially unusual or remote ones.

A key piece of evidence in defective software cases are system logs and event logs, which can provide objective data about how the system was functioning when the error occurred. In-depth analysis of the logs can allow reconstruction of the sequence of events leading up to the failure and identification of the specific error that started the chain of cause and effect. For this reason, it is important that critical systems are equipped with detailed logging mechanisms, and this data is properly stored in case of a dispute.

In more complex cases, it may be necessary to use advanced analysis techniques, such as reverse engineering source code, creating test environments that replicate the conditions under which the failure occurred, or computer simulations that model system behavior. These techniques require the involvement of computer forensics experts who have the expertise necessary to analyze the code and identify potential errors.

Test reports conducted before the software was implemented are also an important piece of evidence. If the tests showed problems in the area that later became the source of the damage, and the manufacturer ignored these signals, this can make a strong case for causation. On the other hand, comprehensive test documentation showing that a particular scenario was tested and worked properly can help defend against allegations of negligence.

In forensic practice, the opinions of independent experts who can assess whether a particular software error could have caused specific consequences are becoming increasingly important. The credibility of such opinions depends on the qualifications of the expert, the methodology of his analysis and access to all relevant data. In complex cases, courts often appoint several independent experts to get a complete picture of the technical aspects of the case.

It is worth noting that some jurisdictions, particularly in consumer cases, have mechanisms in place to facilitate proof of causation. For example, in the case of defective products, including software that is part of a device, there may be a presumption of causation if the damage occurred under normal conditions of use of the product. Similarly, in data protection cases, the RODO introduces the principle of joint and several liability of controllers and processors, which can make it easier for injured parties to pursue claims.

Main methods of proving causation in IT cases

Analysis of system logs - provide objective data about the functioning of the system
Examination of the source code - allows to identify specific errors and their mechanisms of action
Test environments - allow reproduction of conditions leading to failure
Expert opinions - provide expert interpretation of collected evidence
**Design documentatio ** - allows you to assess whether the error was due to a faulty desig
Bug report history - can show that the manufacturer knew about the problem
**Examination of interfaces and integratio ** - relevant to failure of complex systems

What steps should an affected user take in the event of a system failure?

Proper handling of an affected user in the event of an IT system failure is crucial not only to minimize damages, but also to secure the evidence necessary for a potential claim. Systematic and thoughtful action taken immediately after a problem is discovered can significantly affect a user’s position in a potential legal dispute, as well as make it easier for the manufacturer or supplier to quickly diagnose and fix the problem.

The first and fundamental step is to thoroughly document the failure, including the time of occurrence, observed symptoms, error messages and actions taken immediately before the incident. If possible, take screenshots showing errors, save system logs and secure any data on the state of the system at the time of the failure. This documentation is the primary evidence that can be crucial in proving a causal link between a software defect and the resulting damage.

The second step is to immediately report the problem to the software vendor or manufacturer, according to the procedures specified in the contract or technical documentation. The notification should be precise, include all the collected information about the error and clearly indicate expectations on how the problem will be resolved. From a legal perspective, formal notification is crucial, as it starts the response timeframes specified in the SLAs, as well as proves the user’s due diligence in minimizing damages.

For critical business systems whose failure generates significant losses, you should immediately implement the contingency procedures provided for in your Business Continuity Plan. This may include switching to back-up systems, implementing manual procedures or activating alternative service channels. From a legal perspective, the absence of adequate contingency plans or their failure to implement them can be interpreted as the injured party’s contribution to creating or increasing the damage.

If a system failure has caused a personal data breach, the data controller is required to report the incident to the supervisory authority (in Poland, the President of the Office for Personal Data Protection) within 72 hours of detection. In the case of a high risk to the rights and freedoms of individuals, direct notification of data subjects is also necessary. Failure to comply with these obligations can lead to additional sanctions, regardless of liability for the incident itself.

When a failure has caused significant damage and the supplier’s response is inadequate or late, the injured party should consider seeking legal assistance specializing in new technology law. A lawyer can help assess the validity of claims, gather the necessary evidence and prepare a formal demand for compensation. In consumer cases, it may also be helpful to report the case to the city or county consumer ombudsman.

The final step, taken when an amicable resolution of the dispute is not possible, is to take the case to court. Due to the complexity of IT failure cases, the lawsuit should be prepared in detail, indicate the specific legal grounds for the defendant’s liability and include requests for technical evidence, including expert opinions. In many cases, it may also be reasonable to file a motion to secure electronic evidence that may be altered or deleted.

List of actions for the affected user

Accurate documentation of failure- Record the time and circumstances of the problem
Taking screenshots and recording error messages
Securing system logs
Formal bug report- Precise description of the problem according to the procedures
Clearly define expectations for a solution
Retention of confirmation of application and all responses
Implementation of emergency procedures- Activation of backup systems
Launching alternative business processes
Inform stakeholders of the failure and expected repair time
In case of a personal data breach- Report the incident to the DPA within 72 hours
Notification of data subjects (if required)
Documentation of corrective actions take
Taking advantage of legal aid- Consultation with a lawyer specializing in IT
Preparation of a formal request for redress of grievances
For consumers, contact a consumer ombudsma
As a last resort - the judicial route- Filing a lawsuit with a detailed technical description of the problem
Request for appointment of IT experts
Request to secure electronic evidence

How to minimize the risk of liability for software errors, especially in B2B and B2C relationships?

Minimizing the risk of liability for software errors requires a comprehensive approach that includes technical, organizational and legal aspects. An effective strategy for managing this risk should be tailored to the specific nature of the company’s business, the nature of the products it offers and the type of business relationship, with a different approach required in B2B relationships and a different approach in dealing with consumers (B2C).

In B2B (business-to-business) relationships, a key element in minimizing risk is the precise definition of liability in contracts with customers. A well-constructed contract should clearly define what constitutes a software defect, specify procedures for reporting and repairing errors, impose reasonable limits on financial liability (e.g., up to the value of the contract), and exclude liability for indirect damages and lost profits. It is also important to precisely define the functional specification, which is the benchmark for assessing whether the system works as expected.

In the context of a B2C (business-to-consumer) relationship, the possibilities for contractual limitation of liability are much narrower due to the protections afforded to consumers by law. In this case, clear communication with users, including clear information about product limitations, known problems and system requirements, is crucial. It is also important to provide detailed documentation and operating instructions to help users avoid errors resulting from improper use.

From a technical perspective, a fundamental element of risk minimization is the implementation of rigorous quality assurance processes at all stages of the software lifecycle. This includes systematic testing (unit, integration, system, security), regular code reviews, automation of regression testing, and implementation of formal change approval procedures. It is particularly important to test software in conditions that are close to the actual production environment, taking into account various usage scenarios and potential user errors.

An important aspect of risk management is the systematic monitoring and response to bug reports. Implementing an effective incident management system, including processes for prioritization, diagnosis, repair and patch verification, allows problems to be quickly identified and resolved before they cause serious damage. It is also worth considering implementing an early warning system that proactively monitors software performance and alerts you to potential problems.

From an organizational perspective, it is crucial to build a culture of quality and security within development teams. Regular training in programming best practices, application security and legal awareness helps developers understand the consequences of errors and motivates them to be more diligent. It’s also worth considering implementing incentive systems that reward code quality and defect minimization, not just speed of production.

Adequate liability insurance, tailored to the specifics of the IT business, is also an important element in minimizing risk. A professional liability policy or specialized Errors & Omissions insurance can provide financial protection in the event of claims arising from software errors. It is worth remembering, however, that insurance does not absolve the obligation to exercise due diligence and implement appropriate quality assurance procedures.

Strategies for minimizing software liability risks

Area	B2B relationships	B2C relationships
Contracts	Precise limitation of liability, clear specification	Transparent terms, compliance with consumer law
Communications	Formal SLAs, regular status reports	Clear instructions, transparent communication of limitations
Tests	Complex scenarios agreed with the customer	Testing user friendliness and fault tolerance
Documentatio	Detailed technical and design documentatio	User-friendly guides, FAQs
Response to errors	Escalation processes in accordance with the SLA	Easy-to-access support, fast updates
Legal safeguards	Individually negotiated restrictive clauses	Compliance with the requirements of consumer law

How are current regulations responding to the challenges of technology development, including AI?

Modern regulation faces an unprecedented challenge in keeping up with the rapid pace of technology development, particularly in the area of artificial intelligence. Traditional regulatory frameworks, created with static products and clearly defined chains of cause and effect in mind, often prove insufficient in the face of autonomous systems that self-learn and make decisions in ways unpredictable to their creators. This regulatory gap is becoming the subject of intense legislative work around the world, with different jurisdictions taking different approaches to regulating new technologies.

The European Union has taken a proactive approach to regulating the technology, the latest expression of which is the proposed Artificial Intelligence Act (AI Act), which introduces a comprehensive legal framework for the development, deployment and use of AI systems. The regulation takes a risk-based approach, categorizing AI applications according to the level of risk they pose. High-risk AI systems, such as those used in critical infrastructure, education or employment, will be subject to stringent requirements for technical documentation, accuracy, human oversight and tamper-resistance. From a software liability perspective, the AI Act introduces a new standard of due diligence for developers of AI-based systems.

In parallel, the European Union is working on an amendment to the Defective Products Liability Directive to adapt it to the challenges of the digital age. The proposed changes include, among other things, expanding the definition of a product to include software and digital services, taking into account the specifics of self-learning systems, and introducing mechanisms to make it easier for victims to prove causation in the case of damage caused by complex AI systems. In practice, this could mean shifting the burden of proof to the manufacturer in certain circumstances, which will significantly increase the level of liability for software developers.

In the United States, regulation of new technologies is taking a more sectoral and reactive approach, with various regulatory agencies creating guidelines for specific AI applications in their areas of jurisdiction. For example, the Food and Drug Administration (FDA) has developed a framework for regulating Software as a Medical Device (SaMD), including systems using machine learning. The U.S. approach is characterized by a greater emphasis on industry self-regulation and voluntary guidelines, with regulatory interference limited to areas of high risk to public safety.

An interesting trend in the global approach to regulating new technologies is the growing importance of certification mechanisms and industry standards. Faced with the difficulty of creating detailed regulations for rapidly evolving technologies, lawmakers are increasingly referring to technical standards developed by organizations such as ISO and IEEE. For example, the IEEE 7000-2021 standard for the ethical design of autonomous and intelligent systems could become a benchmark for assessing the due diligence of AI system manufacturers.

A particularly significant challenge to the current legal framework is the issue of liability for decisions made by autonomous systems, particularly in the context of self-driving vehicles. In response to these challenges, some jurisdictions are considering introducing the concept of “electronic legal personality” for advanced AI systems, which would allow liability to be assigned directly to the system (and indirectly to the insurance fund behind it). An alternative approach is the concept of “utility owner liability,” which places responsibility on the entity benefiting from the use of the AI system, regardless of its direct control over the system’s decisions.

It is also worth noting the growing importance of “soft regulations” in the form of guidelines, codes of conduct and ethical standards. Although these documents are formally non-binding, in practice they shape the standard of due diligence in the industry and can be a reference point for the courts when assessing liability for errors in modern technology. An example of this approach is the Ethical Guidelines for Trustworthy Artificial Intelligence developed by the European Commission, which promote the principles of transparency, accountability and human oversight of AI systems.

Data protection regulations, such as RODO in Europe and the CCPA in California, are also important in the context of liability for software that uses data. These regulations introduce specific requirements for transparency of algorithms, explainability of decisions and the right to object to decisions made solely by automated means. From the perspective of software developers, this means that they need to implement mechanisms to ensure compliance with these requirements, which can be particularly demanding in the case of advanced machine learning algorithms.

Regulatory evolution in response to new technologies

Risk-based approach - categorizing systems according to potential risks
Certification and standards - the growing role of technical standards as benchmarks
Algorithmic transparency - requirements for explainability of systems’ decisions
Special responsibility for AI - new concepts of responsibility for autonomous systems
**Industry self-regulation ** - codes of conduct and ethical guidelines as a supplement to the law
Shifting the burden of proof - making it easier for victims to pursue claims
**Global harmonizatio ** - aiming for consistent standards internationally

Do programmer ethics affect the software development process and subsequent accountability?

Developer ethics are an increasingly important element in the software development process, influencing both developer practices and potential liability for the consequences of information systems. With the growing importance of technology in social and economic life, there is also a growing awareness of the consequences that can result from decisions made by developers and system architects, leading to the development of formal and informal codes of ethics in the IT environment.

A fundamental principle of programmer ethics is responsibility for the solutions created and their potential consequences. A programmer, aware of the potential consequences of code errors or system misuse, should strive to minimize risks through rigorous testing, in-depth analysis of requirements and implementation of appropriate safeguards. From a legal perspective, knowingly ignoring known risks or potential system misuse can be interpreted as negligence, increasing the software developer’s liability in the event of harm.

A particularly important aspect of software ethics is the issue of transparency and honesty with users. This includes clearly communicating the limitations and potential risks of using the system, avoiding misleading descriptions of functionality, and ensuring that the software meets declared security and performance parameters. In the legal context, a lack of transparency can be grounds for charges of consumer misrepresentation or improper contract performance.

In the case of systems using artificial intelligence and machine learning, programming ethics places particular emphasis on issues related to potential discrimination, algorithm bias and transparency of decision-making processes. A programmer should be aware that algorithms trained on historical data can replicate and reinforce existing social biases, which can lead to discrimination against specific user groups. From a legal perspective, a system that systematically discriminates against certain groups of people may violate equal treatment laws, even if the discrimination was not intended by the developers.

It is worth noting the growing importance of codes of ethics for developers, such as the Software Engineering Code of Ethics and Professional Practice developed by the IEEE and ACM, which formalize standards for ethical behavior in the IT industry. While these documents do not have the force of law, they can provide a benchmark for assessing whether a developer has exercised due diligence and acted in accordance with industry best practices. In the event of litigation, violations of generally recognized ethical principles can be an argument for the existence of negligence.

An interesting trend is the integration of ethical principles into formal software development processes, for example, through Ethical Impact Assessment at the system design stage. This process, analogous to a Data Protection Impact Assessment (DPIA), allows for the systematic identification of potential ethical risks and the development of strategies to minimize them. From a legal liability perspective, a documented ethical analysis process can provide evidence of due diligence and an informed approach to potential system risks.

In the context of software accountability, software ethics provides a kind of bridge between formal-legal requirements and social norms and values. In situations where the law has not kept pace with technology development, ethical standards can fill regulatory gaps, providing an informal but relevant framework for evaluating the actions of software developers. In the long run, ethical principles often evolve into formal legal regulations, which means that conscious adherence to ethical standards can also be a form of preparation for future regulatory requirements.

Impact of software ethics on software liability

Social responsibility - considering the broader impact of the technologies created

**Conscious desig ** - consideration of potential social consequences

Algorithmic transparency - ensuring that the system’s decisions are understandable and explainable

**Avoiding discriminatio ** - testing for bias and prejudice

Prioritizing security - an ethical obligation to minimize risks for users

Respect for privacy - beyond minimum legal requirements

Honesty with users - clear communication of limitations and potential risks