Rules and standards that reach the software itself: OWASP, NIST SSDF, SBOMs, SLSA, the EU Cyber Resilience Act, accessibility (WCAG, Section 508, ADA) and maturity models.
For a long time, compliance for software companies meant compliance of the company: its policies, its offices, its staff. That is changing. Governments now regulate the software product itself, and customers ask how it was built, what it contains and whether everyone can use it.
Secure development
The OWASP Top 10 is an awareness document listing the most critical web application security risks. The OWASP Application Security Verification Standard (ASVS) turns those risks into testable requirements, and OWASP SAMM measures how mature your development process is. NIST's Secure Software Development Framework (SP 800-218) describes practices that US federal agencies expect from their software suppliers. All of these are voluntary in general, and all are widely written into contracts.
Supply chain
A software bill of materials (SBOM) lists the components in your product, and SLSA describes levels of assurance for how it was built. The EU Cyber Resilience Act makes security requirements, vulnerability handling and incident reporting legal obligations for manufacturers of products with digital elements sold in the EU, with obligations applying in stages.
Accessibility
WCAG is the W3C's technical standard for accessible web content. It is voluntary in itself, but laws point to it: the European Accessibility Act, Section 508 for US federal procurement, and US Department of Justice rules under the ADA for state and local government websites.
Process maturity and licences
CMMI appraisals and the OpenChain specification (ISO/IEC 5230) for open source licence compliance are voluntary, but often requested by large customers.
These are the guides closest to our own work. Each one explains what to build, test and document, and where the requirement comes from.
Global practice. Required by the EU Cyber Resilience Act for products sold in the EU, by the US FDA for cyber devices, and by many government and enterprise contracts; recommended by CISA and CERT-In.
Guidance from CISA and NTIA (US), CERT-In (India) and the EU Cyber Resilience Act; formats from the Linux Foundation (SPDX, ISO/IEC 5962) and OWASP (CycloneDX, ECMA-424)
United States federal agencies, and through procurement, vendors that sell information and communication technology to them. Many states and universities adopt it too.
US Congress; standards by the US Access Board; guidance by the General Services Administration (Section508.gov)
United States, applying to electronic records and signatures used to meet FDA requirements, including by companies outside the US that submit data to FDA or make FDA-regulated products.
Global. Applies to software vendors that choose to validate payment-related software under the PCI Security Standards Council programme, often at the request of payment brands, acquirers or customers.
Americans with Disabilities Act: web and mobile app accessibility under Title II (2024 rule, 28 CFR Part 35 Subpart H) and Title III
The Americans with Disabilities Act prohibits disability discrimination, and the US Department of Justice and courts apply it to websites and mobile apps. A 2024 DOJ rule requires state and local governments to make web content and mobile apps conform to WCAG 2.1 Level AA, with compliance dates extended in 2026 to April 2027 for larger entities and April 2028 for smaller ones. Businesses open to the public face Title III claims, with thousands of website accessibility lawsuits filed each year.
Capability Maturity Model Integration (CMMI), version 3.0, from the CMMI Institute (ISACA)
CMMI is a model for improving how organisations deliver software, services and other work. Version 3.0 organises good practices into practice areas across domains such as development, services, supplier management, security, safety, data and people, and defines maturity levels from 1 (initial) to 5 (optimizing). Organisations can be appraised by certified lead appraisers to obtain a maturity level rating, which many IT services companies use to show disciplined delivery to clients and government buyers.
Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)
The Cyber Resilience Act is the EU law that makes cybersecurity a legal requirement for hardware and software products sold in the EU. Manufacturers must design products to essential security requirements, handle vulnerabilities throughout a support period, provide security updates, keep a software bill of materials, carry out conformity assessment and apply CE marking. From 11 September 2026 they must report actively exploited vulnerabilities and severe incidents within 24 hours, and most other duties apply from December 2027.
NIST Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1
The NIST Secure Software Development Framework is a set of high-level practices for building secure software, organised in four groups: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities. It is technology-neutral and maps to other secure development models. US federal policy used it as the basis for supplier attestations until a January 2026 OMB memo made that agency-specific, but it remains the most common reference for secure development expectations.
ISO/IEC 5230:2020 OpenChain Specification for open source license compliance, with ISO/IEC 18974 for open source security assurance
ISO/IEC 5230, the OpenChain Specification, defines the key requirements of a quality open source license compliance program. It does not dictate tools or processes; it requires a policy, trained staff, assigned roles, a process to identify and review open source components, compliance artifacts such as notices and source code, and a contribution policy. Its sister standard, ISO/IEC 18974, covers open source security assurance. Organisations can self-certify, and updated versions are planned for 2026.
OWASP Application Security Verification Standard, version 5.0
The OWASP Application Security Verification Standard is a detailed, testable list of security requirements for web applications and APIs. Version 5.0, released in May 2025, organises around 350 requirements into 17 chapters, from encoding and validation to authentication, authorisation, cryptography, logging and WebRTC, and three levels of assurance. Teams use it to define security requirements, design tests and agree contractual security expectations, going far beyond the awareness-level OWASP Top 10.
OWASP Software Assurance Maturity Model, version 2
OWASP SAMM is an open framework for assessing and improving how an organisation builds secure software. It defines five business functions (Governance, Design, Implementation, Verification and Operations), each with three security practices, and maturity levels for each practice. Teams score their current state, choose targets that fit their risk, and build a roadmap. It complements requirement standards such as the OWASP ASVS and frameworks such as the NIST SSDF, and it is free to use.
OWASP Top 10:2025, the ten most critical web application security risks
The OWASP Top 10 is the best-known list of critical web application security risks, published by the OWASP Foundation from data on millions of tested applications and a community survey. The 2025 edition, the eighth, ranks broken access control first and adds two categories: software supply chain failures and mishandling of exceptional conditions. It is an awareness document rather than a standard, but secure coding policies, PCI DSS assessments, penetration tests and customer contracts routinely use it as a baseline.
Software Bill of Materials: minimum elements, formats and regulatory expectations
A software bill of materials is a machine-readable inventory of the components in a piece of software, including open-source and third-party libraries, with versions and relationships. It lets producers and customers find out quickly whether a newly disclosed vulnerability affects them. SBOMs are now required for products under the EU Cyber Resilience Act and for FDA cyber device submissions, recommended by CISA and CERT-In, and increasingly requested in enterprise and government contracts.
Section 508 of the Rehabilitation Act of 1973 and the Revised 508 Standards for information and communication technology (36 CFR Part 1194)
Section 508 requires US federal agencies to make the information and communication technology they develop, buy, maintain or use accessible to people with disabilities. The Revised 508 Standards, in force since January 2018, incorporate WCAG 2.0 Level A and AA for web content, documents and software, and add requirements for hardware, support documentation and services. Vendors selling to agencies are asked for an Accessibility Conformance Report, usually based on the VPAT template, and may face accessibility testing.
Supply-chain Levels for Software Artifacts (SLSA), an OpenSSF specification
SLSA is an open specification for protecting software from tampering between source code and the package users install. It defines tracks with increasing levels: the Build track, from provenance that describes how an artifact was built up to hardened, isolated builds with signed provenance, and the Source track, from version control up to enforced controls and two-party review. Producers generate attestations, and consumers verify them before trusting an artifact.
WCAG is the international technical standard for making web content and applications accessible to people with disabilities. Version 2.2 organises 86 success criteria under four principles (perceivable, operable, understandable, robust) and three conformance levels, with Level AA the usual legal target. WCAG itself is voluntary, but laws in the EU, US, UK and India require conformance to it or to standards based on it, so most public-facing digital products now need to meet it.
Title 21 Code of Federal Regulations Part 11: Electronic Records; Electronic Signatures (US Food and Drug Administration)
21 CFR Part 11 sets the conditions under which the FDA accepts electronic records and electronic signatures as equivalent to paper records and handwritten signatures. It requires validated systems, secure computer-generated audit trails, access and authority controls, record protection and retention, and controls for unique, verified electronic signatures linked to records. FDA guidance narrows its scope, applies risk-based thinking, and, for device makers, promotes computer software assurance over heavy documentation.
Directive (EU) 2019/882 on the accessibility requirements for products and services (European Accessibility Act)
The European Accessibility Act is an EU directive that sets common accessibility requirements for key products and services, including e-commerce, consumer banking, e-books, electronic communications, passenger transport services, computers, smartphones and self-service terminals. Since 28 June 2025, businesses offering these to EU consumers must make them accessible, usually by meeting the harmonised standard EN 301 549, which incorporates WCAG 2.1 AA for web content. It applies to non-EU companies selling into the EU.
IEC 62304: Medical device software, Software life cycle processes (Edition 1.1, IEC 62304:2006+AMD1:2015)
IEC 62304 defines the software life cycle processes for medical device software, including standalone software as a medical device. It classifies software into safety classes A, B and C based on the harm a failure could cause, then scales requirements for planning, requirements, architecture, design, implementation, verification, release, maintenance, risk management, configuration management and problem resolution. Regulators in the US and EU expect conformance, and a second edition broadening scope to health software is in development.
PCI Software Security Framework: PCI Secure Software Standard and PCI Secure Software Lifecycle (Secure SLC) Standard
The PCI Software Security Framework replaced PA-DSS with two standards: the Secure Software Standard, which validates the security of specific software products, and the Secure SLC Standard, which validates a vendor's secure software development lifecycle. Version 2.0 of the Secure Software Standard, effective January 2026, takes a principles-based approach focused on protecting sensitive assets, adds a module for SDKs, requires source code access for assessors, and lets Secure SLC qualified vendors self-approve low-impact updates.
OWASP describes it as an awareness document, not a standard. It is referenced by other standards and contracts. For testable requirements, use the OWASP ASVS.
Does the EU Cyber Resilience Act apply to software made outside the EU?
It applies to products with digital elements made available on the EU market, wherever they are made. The CRA guide explains the scope, the exemptions and the dates.
Is WCAG a law?
WCAG itself is a W3C standard. Several laws and regulations require conformance with it or with standards based on it, which is how it becomes mandatory.
We build the parts auditors and privacy laws look for: role-based access, audit logs, encryption, consent records, data export and erasure, and secure development practices. Tell us about your product and get a free quote within one business day.
