The software development landscape is rapidly changing, with legislation emerging as a key driver of industry trends. As our reliance on software and AI grows, so does our vulnerability to cybercrime, which is now a multi-trillion-dollar problem. This has caught the attention of regulators worldwide.
This article explains the various regulatory efforts in play and summarises actions that developers and executives should consider as they get to grips with 2025 – the year of software legislation
Part 1 covered the background, what a software supply chain is and thoughts on AI and open source.
Part 2 explored how governments are working to create legislation and what the current status is.
Part 3 offered both a Software supply chain and an AI governance & compliance checklists for developers and executives to consider
Part 4 (this article) discusses cybersecurity and incident reporting requirements, examines geopolitical compliance and liability management, and wraps up the series.
There’s a lot to take in. I hope you’re sitting comfortably..
Accountability Cannot be Outsourced.
I am not a lawyer. This document is a technical view of the legislation and regulations being developed or repurposed. It’s imperative to get your own legal assessment when deciding if these elements apply to your situation. Having said that, some aspects are shared. The primary one is accountability. There’s no dodging your responsibilities. That means wherever you are in the software supply chain, you have responsibilities to those consuming your software and those using it. Regulations collectively require organisations to assess, monitor, and manage third-party risks, and you’ll have to prove that you did the right thing at the right time.
Blaming others without proper due diligence and safeguards is not a valid defence!
The following sections list commercial tools. They are for example only and do not constitute recommendations or endorsements.
Cybersecurity & Incident Reporting
Implement forensic-grade logging and monitoring.
Your logging and monitoring must meet forensic-grade standards to support post-incident investigations and compliance obligations. Logs should be tamper-evident, timestamped with synchronized time sources (e.g., via NTP), and stored securely with access controls and retention policies. Capture logs from all layers (application, infrastructure, authentication systems, APIs, and user interactions, etc) and enrich them with context (e.g., user ID, IP, session ID). Use centralized logging platforms like Elastic Stack, Datadog, or Splunk and integrate with SIEM tools for real-time threat detection. Protect logs from modification and ensure they are retained per your regulatory obligations (e.g., PCI-DSS, HIPAA, GDPR). Wazuh is a good starting point for building a forensic-grade logging and intrusion detection system for open-source teams.
Establish and test incident response plans.
An incident response plan (IRP) is your playbook for responding to security incidents efficiently and legally. It should define roles (e.g., incident commander, communications lead), escalation paths, forensic evidence handling, containment and recovery procedures, and post-mortem workflows. Base your IRP on established frameworks like NIST SP 800-61 or ISO/IEC 27035. Test your plan regularly to ensure readiness. After each test or real-world incident, perform a structured lessons-learned review and update the plan accordingly. Store the plan in an easily accessible location and ensure key team members can activate it quickly, even outside office hours.
Ensure regulatory compliance with mandatory breach reporting timelines.
Different jurisdictions impose specific timelines for breach notifications, and failure to comply can result in steep penalties. For instance, GDPR mandates breach reporting to authorities within 72 hours, while U.S. states have their own timelines, and SEC cyber rules may require public disclosure within four business days. Maintain a regulatory mapping document that details breach notification timelines across all applicable jurisdictions where your organization operates. Your legal and compliance teams should be looped into the incident response process early to determine reportability and notification obligations. Use automated triggers in your IRP to initiate legal review the moment a suspected breach crosses severity or data exposure thresholds.
Develop and document processes for rapid regulatory notification and containment of security incidents.
Speed matters during a breach, and regulators expect evidence of preparedness. Create a documented playbook for notifying regulators and affected stakeholders, including pre-approved communication templates, escalation paths, and designated contact points. Map out decision trees for when to notify which regulator, customers, and law enforcement. Include templates for initial notifications, progress updates, and final reports, and ensure they’re stored in a secure but easily accessible location (e.g., within your incident response dashboard or GRC tool). Establish a cross-functional breach response team involving legal, PR, IT, and engineering, and rehearse multi-stakeholder simulations. Consider leveraging tooling like Drata, Vanta, or GRC platforms to centralize incident documentation and reduce time-to-report.
Geopolitical Compliance and Liability Management
Screen all customers against export control lists.
Before onboarding customers, especially in international markets, screen them against government export control lists such as the U.S. Department of Commerce Entity List, OFAC sanctions list, and relevant EU or UK restrictions. Use automated tools like Descartes Visual Compliance or LexisNexis Bridger Insight to integrate these checks into your customer onboarding process. Document the outcome of each check to maintain a compliance trail and flag any entities located in embargoed regions or under restricted technology access. Failing to do this can result in severe penalties, export license revocation, or reputational damage.
Implement regional data hosting options to comply with localization laws.
Data localization laws in countries like China, Russia, India, and parts of the EU (e.g., GDPR) require that certain types of data (especially personal or sensitive information ) be stored and processed within national borders. Offer customers regional data hosting choices using cloud providers like AWS Local Zones, Azure Regional Services, or Google Cloud’s data residency controls. Use GDPR-compliant processors and ensure contracts include standard contractual clauses (SCCs) or binding corporate rules (BCRs) as needed. Maintain a data residency matrix and map workloads accordingly to ensure legal and contractual compliance.
Track and document all software dependencies to ensure compliance.
Managing third-party software usage, both open-source and proprietary, is essential for legal and security compliance. Maintain a real-time, searchable inventory of all components using tools like FOSSA, Snyk, or OWASP Dependency-Track. This helps you comply with licensing terms (e.g., GPL, AGPL), avoid IP infringement, and meet disclosure obligations (e.g., via SBOMs). Include each dependency’s version, source, license, and usage context in your records. Ensure license policy enforcement (e.g., banning copyleft licenses in commercial products) and run automated scans during CI to flag violations before code merges.
Ensure compliance with cybersecurity trade restrictions, including bans on foreign software use in critical sectors.
Governments are increasingly restricting the use of foreign-developed software in sensitive sectors such as defence, finance, and energy. For instance, the U.S. bans certain Chinese-developed software and apps from federal systems, and the EU has rules regarding telecom infrastructure and data sovereignty. Regularly audit your software stack, including infrastructure and build tools, for foreign-origin components that may trigger compliance issues. Maintain an internal software classification by origin and criticality and assess against regulations like the U.S. Federal Acquisition Regulation (FAR) or the EU Cybersecurity Act. Seeking legal counsel and obtaining alternative domestic solutions or certified suppliers where necessary.
Prepare internal risk assessments for emerging regulations on AI liability.
AI liability legislation is rapidly evolving. The EU AI Act introduces obligations for risk categorization, documentation, and human oversight, while U.S. and UK proposals are increasingly focused on accountability for harm. Prepare for these shifts by conducting internal risk assessments of your AI systems, focusing on model use cases, decision impact, and failure modes. Use frameworks like NIST AI RMF and tools like AI Explainability 360 to assess governance and control measures. Maintain a register of high-risk use cases and define policies for auditing, escalation, and responsible deprecation of AI systems that pose liability risks.
Educate engineering teams on evolving software liability laws to reduce legal exposure.
Legal frameworks are starting to hold software producers accountable for insecure or harmful code, especially in safety-critical and AI-driven systems. Host regular legal briefings or brown-bag sessions with your legal team to inform engineers of relevant changes like the EU Cyber Resilience Act or proposed U.S. rules around software liability. Develop training programs or onboarding modules that cover secure coding, licensing compliance, and responsible AI development. Emphasize the concept of engineering defensibility: the idea that your codebase, process, and documentation should hold up to external scrutiny in case of a breach or failure.
Develop compliance roadmaps to keep up with regulatory changes over time.
Staying compliant is not a one-time effort; it’s an evolving strategy. Assign responsibility to a cross-functional team (legal, security, DevOps, product) to monitor emerging tech regulations globally and update internal policies accordingly. Use a compliance roadmap to plan upcoming changes, such as adopting new standards (e.g., SBOM formats), implementing localization controls, or adapting to new AI liability rules. Tools like OneTrust, TrustArc, or even a simple roadmap tracker in Confluence or GitHub can help. Communicate this roadmap across teams so engineering and product planning can anticipate regulatory needs in advance.
Wrap Up
There’s a lot to unpack, and we’ve barely started. The clock is ticking, though, and it’s time to start acting. For any significant endeavour, you’ll need legal advice. From an open-source project POV, you could do nothing, and apart from potentially losing users, there’s little sign that you have any of these obligations. The requirements will continue to grow for everyone else involved in providing software services or products, and the open-source projects that rise to the challenge will gain even more adoption.
However, weaving through the legal considerations is concern over harm. Vulnerable software has often had the potential to cause actual harm to people, and some recent cyber-attacks have played on that fear – or even been capable of inflicting it.
Be alert: as laws evolve, the old assumption that open source == no liability is being challenged, particularly for AI tools that generate content or make decisions. Those using or building on generative OSS tools may soon face new legal expectations, compliance demands, or shared responsibility for harm.
Remember, accountability cannot be outsourced – for commercial organisations and potentially for some OSS tools:
- Your Responsibility: You remain liable when using third-party software or AI models.
- Due Diligence Required: Regulations mandate a thorough assessment of all components.
- No Blame Shifting: You can’t claim “not my code” when vulnerabilities impact or harm users.
Using third-party code or models does not transfer legal responsibility. Your organization must ensure that all components meet regulatory requirements.
