Software development compliance is about how code is written, tested, shipped and maintained. Most of it starts as voluntary guidance (OWASP, NIST SSDF, CMMI), but buyers and laws increasingly turn it into a requirement: US federal suppliers attest to secure development practices, the EU Cyber Resilience Act expects vulnerability handling, and accessibility laws point to WCAG.
6 items in this category
6 related from other categories
Oct 30, 2026 statuses last checked
At a glance
Software development compliance compared
How the items in this category differ on the question that matters first: do you have to, or do you choose to?
Name
Type
Mandatory or voluntary
Where it applies
Current version
OWASP Top 10
Guidance
Voluntary guidance, no official certificate
Global
OWASP Top 10:2025.
OWASP ASVS
Guidance
Voluntary guidance, no official certificate
Global
ASVS 5.0, released in May 2025.
NIST SSDF
Framework
Voluntary framework, no official certificate
United States, used worldwide
SP 800-218 version 1.1, with an update in progress; re-checked at every review.
SBOM and supply chain
Guidance
Voluntary guidance, no official certificate
United States and EU, used worldwide
SBOM duties appear in the EU Cyber Resilience Act and in US federal software procurement.
CMMI
Certifiable standard
Voluntary, with independent certification
Global
CMMI v3.0 (2023).
WCAG 2.2
Guidance
Voluntary guidance, no official certificate
Global; required through US and EU laws
WCAG 2.2 published October 2023. The European Accessibility Act has applied since 28 June 2025.
Directory
What each one covers and who needs it
Guidance Global
OWASP Top 10
Open Worldwide Application Security Project Top 10 web application security risks
The OWASP Top 10 is an awareness document listing the most critical security risks to web applications, based on data from real applications and a community survey. It is updated every few years; the 2025 edition keeps broken access control at the top and adds software supply chain failures. It is not a standard and cannot be certified, but PCI DSS, customers and penetration testers use it as the minimum set of risks your developers must understand and test for.
What it covers, who needs it and why
What it covers
Access control, misconfiguration, supply chain, cryptography, injection, insecure design, authentication, integrity, logging and alerting, and error handling.
Who needs it
Every team that builds web applications or APIs, and the security testers and buyers who assess them.
Why it matters
It is the shared baseline for secure coding training and application security testing.
The ASVS is a detailed list of security requirements for designing, building and testing web applications and APIs. Requirements are grouped by area and assigned to three levels: Level 1 for basic assurance, Level 2 for most applications that handle sensitive data, and Level 3 for the most critical systems. Where the Top 10 tells you what to worry about, the ASVS tells you what to verify. It is free and widely used to write security requirements into contracts and test plans.
What it covers, who needs it and why
What it covers
Authentication, session management, access control, validation and encoding, cryptography, error handling and logging, data protection, communications, configuration and API security.
Who needs it
Development teams, application security testers, and buyers who want measurable security requirements from software vendors.
Why it matters
It turns "secure software" into testable requirements a customer and vendor can agree on.
NIST SP 800-218, Secure Software Development Framework (SSDF)
The SSDF is a set of secure software development practices organized into four groups: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. It is outcome-based and works with any development method. US federal agencies require software producers to attest that they follow key SSDF practices, using CISA's secure software development attestation form, so it has become a real requirement for vendors selling software to the US government.
What it covers, who needs it and why
What it covers
Development environment security, code integrity, secure design and coding, testing, third-party components, vulnerability disclosure and remediation.
Who needs it
Software producers, especially those selling to US federal agencies or their prime contractors.
Why it matters
Federal buyers ask for the attestation, and it lines up well with the EU Cyber Resilience Act's vulnerability handling duties.
Key objectives
Reduce vulnerabilities in released software
Limit the impact of vulnerabilities that remain
Address root causes to prevent recurrence
Mandatory or voluntary
Voluntary framework, no official certificate.
Owner
NIST
Current version
SP 800-218 version 1.1, with an update in progress; re-checked at every review.
Software bill of materials (SPDX, CycloneDX) and supply chain frameworks such as SLSA
A software bill of materials (SBOM) is a machine-readable list of the components inside a piece of software, usually in the SPDX or CycloneDX format. It lets producers and customers find affected products quickly when a vulnerability appears in a library. Supply chain frameworks such as SLSA add levels of build integrity and provenance. The EU Cyber Resilience Act requires manufacturers to draw up an SBOM, and US federal buyers increasingly ask for one.
What it covers, who needs it and why
What it covers
Component inventory, dependency management, build provenance, signing and vulnerability response for third-party and open source code.
Who needs it
Software publishers, SaaS companies that ship agents or on-premises editions, and teams that rely heavily on open source.
Why it matters
Supply chain attacks and library vulnerabilities are now among the top application risks, and regulators expect you to know what you ship.
Key objectives
Know every component you ship
Prove build integrity
Respond fast to component vulnerabilities
Mandatory or voluntary
Voluntary guidance, no official certificate.
Owner
CISA, NTIA guidance, the Linux Foundation (SPDX), OWASP (CycloneDX) and OpenSSF (SLSA)
Current version
SBOM duties appear in the EU Cyber Resilience Act and in US federal software procurement.
CMMI is a model of best practices for developing products and delivering services, with maturity levels that describe how well an organization's processes are defined, managed and improved. Organizations are appraised by certified lead appraisers, and the results are published by ISACA, so a "CMMI Level 3" claim can be checked. It is voluntary but common in software outsourcing and government contracts, particularly for Indian IT services firms.
What it covers, who needs it and why
What it covers
Practice areas for planning, estimating, requirements, design, verification, configuration management, process improvement and, in v3.0, security, safety and data management.
Who needs it
Software development and IT services companies bidding for large outsourcing or government programs.
Why it matters
Some buyers require a specific maturity level as a bid condition.
Web Content Accessibility Guidelines 2.2, and the laws that reference them (ADA, Section 508, European Accessibility Act)
WCAG 2.2 is the W3C standard for making web content and software usable by people with disabilities, organized under four principles (perceivable, operable, understandable, robust) and three conformance levels, with AA the usual legal target. WCAG itself is voluntary, but laws point to it: Section 508 for US federal technology, ADA rules for state and local government websites, and the EN 301 549 standard behind the European Accessibility Act, which covers e-commerce, banking and e-books sold in the EU.
What it covers, who needs it and why
What it covers
Text alternatives, captions, keyboard access, focus, contrast, forms, error handling, consistent navigation and compatibility with assistive technology.
Who needs it
Software, SaaS and website owners selling to governments, public bodies, schools, or EU consumers in covered sectors.
Why it matters
Public buyers ask for an accessibility conformance report, and accessibility lawsuits and EU enforcement are growing.
Key objectives
Make digital products usable by everyone
Give testable success criteria
Support legal compliance
Mandatory or voluntary
Voluntary guidance, no official certificate.
Owner
W3C (WCAG); US Department of Justice and Access Board; European Union (EAA)
Current version
WCAG 2.2 published October 2023. The European Accessibility Act has applied since 28 June 2025.
Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements
The Cyber Resilience Act sets cybersecurity requirements for hardware and software products with digital elements sold in the EU. Manufacturers must design products to essential security requirements, handle vulnerabilities for the support period, provide security updates, document a software bill of materials, and carry a CE mark. Since 11 September 2026 they must report actively exploited vulnerabilities and severe incidents to ENISA's single reporting platform within 24 hours. Pure SaaS is mostly covered by NIS2 instead, except where it is remote data processing for a product.
What it covers, who needs it and why
What it covers
Software and connected products placed on the EU market, from design and vulnerability handling to updates, documentation and conformity assessment.
Who needs it
Manufacturers, importers and distributors of software and connected devices for the EU market, including non-EU software publishers.
Why it matters
It is the first EU law to put security-by-design duties on software makers, with fines up to 15 million euros or 2.5% of turnover.
Key objectives
Ship products with fewer vulnerabilities
Keep products secure through their support period
Give users clear security information
Report exploited vulnerabilities fast
Mandatory or voluntary
Mandatory for regulated organizations in scope.
Owner
European Union; market surveillance authorities and ENISA
Current version
In force since 10 December 2024. Reporting of actively exploited vulnerabilities and severe incidents applies from 11 September 2026; the remaining obligations from 11 December 2027.
ISO 9001 is the international standard for a quality management system. It asks you to understand customer requirements, plan and control the processes that deliver your products and services, manage risks and opportunities, measure results and improve. For software and IT companies it is often a tender requirement, especially in government and manufacturing supply chains. The 2026 edition adds emphasis on quality culture and ethics, change management and organizational knowledge.
What it covers, who needs it and why
What it covers
Leadership, planning, support (people, competence, documented information), operations (design, development, delivery), performance evaluation and improvement.
Who needs it
Software development firms, IT service companies and any supplier whose customers require a certified quality system.
Why it matters
It is the most widely held management system certificate in the world and a common pre-qualification filter.
Key objectives
Consistently meet customer and legal requirements
Manage processes and risks
Improve customer satisfaction
Mandatory or voluntary
Voluntary, with independent certification.
Owner
ISO (TC 176)
Current version
ISO 9001:2026 was published on 16 September 2026, with a transition period of about three years. ISO 9001:2015 certificates stay valid during the transition.
PCI Software Security Framework: Secure Software Standard and Secure SLC Standard
The PCI Secure Software Standard sets security requirements for payment software that stores, processes or transmits card data, and the Secure Software Lifecycle (Secure SLC) Standard assesses how a vendor develops and maintains it. Software validated by an assessor appears on the PCI SSC list, which merchants and acquirers use when choosing payment applications. It replaced the older PA-DSS program.
What it covers, who needs it and why
What it covers
Payment software design, sensitive data protection, authentication, attack resistance, vendor security guidance, and the vendor's development lifecycle.
Who needs it
Vendors of payment applications, POS software, payment gateways and SDKs that handle card data.
Why it matters
Merchants and acquirers prefer or require listed software, and it simplifies their own PCI DSS scope.
Key objectives
Build payment software securely
Protect card data inside the application
Give merchants validated choices
Mandatory or voluntary
Mandatory once a contract, card brand or government buyer requires it.
Owner
PCI Security Standards Council
Current version
Part of the PCI Software Security Framework, which replaced PA-DSS (retired in 2022).
Regulation United States (FDA-regulated activities)
21 CFR Part 11
FDA regulation on electronic records and electronic signatures, Title 21 Code of Federal Regulations Part 11
Part 11 sets the conditions under which the FDA treats electronic records and signatures as equivalent to paper. It applies to records that FDA predicate rules require pharmaceutical, biotech, medical device and food companies to keep. Systems must be validated, keep secure, computer-generated audit trails, limit access, and link electronic signatures to their records. FDA's 2003 guidance narrowed enforcement focus, so the first job is deciding which records are actually Part 11 records.
What it covers, who needs it and why
What it covers
Electronic records required by FDA rules and the systems that create, modify, store and sign them, including training, quality and clinical systems.
Who needs it
FDA-regulated life sciences companies and the software vendors whose systems hold their regulated records.
Why it matters
FDA inspectors cite Part 11 gaps in warning letters, and life sciences buyers validate vendors against it.
Key objectives
Trustworthy and reliable electronic records
Secure audit trails
Legally binding electronic signatures
Mandatory or voluntary
Mandatory for regulated organizations in scope.
Owner
US Food and Drug Administration (FDA)
Current version
The 1997 rule, read with FDA's 2003 guidance on scope and application.
Regulation EU, plus non-EU providers whose AI is placed on the EU market or used there
EU AI Act
Artificial Intelligence Act, Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744
The EU AI Act regulates AI by risk. A short list of practices is banned. High-risk systems, such as AI used in hiring, education, credit scoring or critical infrastructure, need risk management, data governance, documentation, logging, human oversight, accuracy and robustness, plus conformity assessment. Chatbots and generative AI carry transparency duties, and general-purpose AI model providers have their own obligations. It binds providers and deployers, including non-EU companies. The top fines reach 35 million euros or 7% of turnover.
What it covers, who needs it and why
What it covers
AI systems and general-purpose AI models placed on the EU market or used in the EU, across their lifecycle.
Who needs it
Companies that build AI features, sell AI products into the EU, or use high-risk AI in the EU, including HR tech, edtech and fintech vendors.
Why it matters
It is the first comprehensive AI law, its phased dates are already running, and customers now ask vendors about AI Act roles and duties.
Key objectives
Ban unacceptable AI practices
Make high-risk AI safe and accountable
Give people transparency when AI is used
Govern general-purpose AI models
Mandatory or voluntary
Mandatory for regulated organizations in scope.
Owner
European Union; the AI Office and national market surveillance authorities
Current version
Prohibitions apply since 2 February 2025 and general-purpose AI model duties since 2 August 2025. After the Digital Omnibus amendment (Regulation 2026/1744), Annex III high-risk duties apply from 2 December 2027 and Annex I from 2 August 2028.
OWASP Top 10 for Large Language Model Applications
The OWASP Top 10 for LLM Applications lists the most critical security risks in applications built on large language models, starting with prompt injection and including sensitive information disclosure, supply chain risks, data and model poisoning, improper output handling, excessive agency and unbounded consumption. Like the web Top 10, it is an awareness document, not a certifiable standard. It is the practical checklist most security reviewers now use for chatbots, AI assistants and agents.
What it covers, who needs it and why
What it covers
Prompt handling, model and data supply chain, output handling, plugin and tool permissions, data leakage, system prompts, vector stores and resource abuse.
Who needs it
Teams building chatbots, AI assistants, agents and other LLM features, and the security teams that test them.
Why it matters
LLM features open new attack paths that traditional application security testing misses.
Train your team on software development requirements
Most of these frameworks expect trained staff and records to prove it. LMS Advisor assigns the right courses by role, sends reminders, renews certificates on schedule and keeps an audit trail you can export.
Due dates, reminders and overdue reports for mandatory courses
Certificates that expire and renew on your retraining cycle
CSV, Excel and PDF exports of who completed what, and when
LMS Advisor is our product. It runs your training and keeps the records. It does not certify you against any standard.
Book a demo before Dec 1, 2026 and your quote comes with 30% off your first year of LMS Advisor: courses, proctored exams, certificates and AI authoring in one platform, in our cloud or on your own server.
Offer ends Dec 1, 2026, 11:59 PM ET
Cloud or self-hosted, proctoring included
The discount is applied in your written quote
We use cookies to see how visitors use this site and to measure our ads. Choose Continue to allow them, or Reject to browse without them. Privacy policy
LMS Advisor AI
AI product consultant
You're chatting with an AI. Answers can be wrong, so please don't type personal data here. Privacy ·
