Standards for building software securely, from coding and testing to supply chain and vulnerability handling. 7 entries, 2 with a full guide.
Clients and regulators now ask software companies to prove that security is built into development, not tested at the end. The questions cover secure coding, dependency management, code review, testing and how you handle vulnerabilities after release.
The OWASP Top 10 is the most cited awareness list of web application risks and is the usual baseline for penetration tests. OWASP ASVS turns it into testable requirements, and the NIST Secure Software Development Framework (SP 800-218) describes secure SDLC practices that US federal buyers expect.
Regulation is arriving too: the EU Cyber Resilience Act's vulnerability reporting duties have applied since 11 September 2026, and its main requirements apply from 11 December 2027 to most software products sold in the EU.
ISO 9001:2026 Quality management systems: Requirements
Certifiable standardVoluntaryGlobal
ISO 9001 is the international standard for a quality management system (QMS). It asks you to understand customer and stakeholder requirements, plan processes and risks, control how you design and deliver products and services, measure customer satisfaction and keep improving. For software and IT services firms it formalises requirements management, design and development control, testing, change control and supplier management. The 2026 edition was published in September 2026.
Covers, who needs it and key requirements
What it covers
Context and interested parties, quality policy and objectives, risks and opportunities, competence and awareness, operational planning, requirements review, design and development, supplier control, release, nonconforming outputs, customer satisfaction, internal audit and improvement.
Who needs it
Software development companies, IT services and managed service providers, system integrators and any supplier asked for a quality certificate in RFPs or government tenders.
Why it matters
It is the most widely held management system certificate in the world and a common minimum requirement in public and enterprise procurement.
OWASP Top 10:2025 The Ten Most Critical Web Application Security Risks
Awareness standardVoluntaryGlobal
The OWASP Top 10 is the most widely used awareness list of critical web application security risks, published by the non-profit OWASP Foundation from vulnerability data and community surveys. The 2025 edition, released in November 2025, ranks Broken Access Control first, adds Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10), and folds SSRF into access control. It is a starting point for secure coding, testing and developer training, not a complete standard.
Covers, who needs it and key requirements
What it covers
A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, A10 Mishandling of Exceptional Conditions.
Who needs it
Software development companies, web and app agencies, SaaS teams, QA and penetration testing providers, and any team building web applications or APIs.
Why it matters
Clients, PCI DSS assessors and pen testers use it as the baseline, so building and testing against it avoids the most common and most expensive application flaws.
Enforce access control on the server for every request (A01)
Harden configurations and remove defaults (A02)
Manage dependencies, build pipelines and SBOMs (A03)
Use strong, current cryptography and protect secrets (A04)
Use parameterised queries and output encoding (A05) and threat-model designs (A06)
Strong authentication, integrity checks, logging with alerting, and safe error handling (A07 to A10)
Cyber Resilience Act
Cyber Resilience Act, Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements
LawMandatory if in scopeEU
The Cyber Resilience Act sets cybersecurity requirements for hardware and software products with digital elements sold in the EU. Manufacturers must design products securely, handle vulnerabilities for the support period, provide security updates and an SBOM, and carry out conformity assessment and CE marking. Reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026; the main requirements apply from 11 December 2027. Fines reach EUR 15 million or 2.5% of turnover.
Covers, who needs it and key requirements
What it covers
Security by design, vulnerability handling, security updates, SBOMs, technical documentation, conformity assessment, CE marking and reporting of exploited vulnerabilities and incidents for products with digital elements.
Who needs it
Manufacturers, importers and distributors of software and connected products placed on the EU market, including software companies selling licensed products. Pure SaaS is mostly covered by NIS2 instead.
Why it matters
It makes secure development and vulnerability handling a legal condition for selling software and connected products in the EU.
Applies in
European Union; applies to products placed on the EU market from anywhere
Meet the essential cybersecurity requirements in Annex I
Vulnerability handling for the support period, with an SBOM
Report actively exploited vulnerabilities and severe incidents (early warning within 24 hours)
Conformity assessment and CE marking before placing on the market
Technical documentation and user security information
NIST SSDF (SP 800-218)
NIST SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
FrameworkMandatory if in scopeUS / global
The Secure Software Development Framework (NIST SP 800-218) is a set of high-level secure development practices grouped into four areas: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities. Software producers selling to US federal agencies attest to it through the CISA secure software development attestation form. Version 1.1 is final, and NIST published a draft Version 1.2 in December 2025.
Covers, who needs it and key requirements
What it covers
Secure development policies and roles, protecting code and build environments, secure design, code review and testing, provenance and SBOM practices, and vulnerability response.
Who needs it
Software producers selling to US federal agencies, and any software company wanting a recognised secure SDLC framework.
Why it matters
Federal buyers require attestation to it, and it maps to the EU Cyber Resilience Act and client secure development questionnaires.
Prepare the organisation (PO): roles, training, toolchains
Protect the software (PS): code integrity, provenance, archived releases
Produce well-secured software (PW): design, review, testing, secure defaults
Respond to vulnerabilities (RV): identify, analyse and fix root causes
OWASP ASVS
OWASP Application Security Verification Standard 5.0
FrameworkVoluntaryGlobal
The OWASP Application Security Verification Standard gives testable security requirements for web applications and services, organised in three levels of rigour. Version 5.0, released in May 2025, restructured the requirements and is widely used to define what a secure application must do, to scope penetration tests and to write security acceptance criteria in development contracts. Where the OWASP Top 10 lists risks, ASVS says how to verify that controls are in place.
Covers, who needs it and key requirements
What it covers
Verification requirements for architecture, authentication, session management, access control, validation, cryptography, error handling, data protection, communications, configuration and APIs.
Who needs it
Development teams, software companies, QA and penetration testers, and clients writing security requirements into contracts.
Why it matters
It turns secure coding into measurable acceptance criteria and test cases.
Choose a verification level (L1, L2 or L3) per application
Use ASVS requirements as security user stories and acceptance criteria
Verify with code review, automated tests and penetration testing
Track and fix gaps before release
WCAG 2.2
Web Content Accessibility Guidelines (WCAG) 2.2
FrameworkMandatory if in scopeGlobal
WCAG 2.2 is the W3C standard for making web content and apps accessible to people with disabilities, published as a W3C Recommendation in October 2023. Its success criteria are grouped under four principles (perceivable, operable, understandable, robust) at levels A, AA and AAA. Level AA is the benchmark referenced by laws and procurement rules such as the European Accessibility Act (through EN 301 549), US Section 508 and ADA settlements, and Indian government guidelines.
Covers, who needs it and key requirements
What it covers
Text alternatives, captions, adaptable and distinguishable content, keyboard access, timing, navigation, input modalities, readable and predictable interfaces, and compatibility with assistive technologies.
Who needs it
Software and web development companies, SaaS and e-commerce businesses, and anyone selling digital products to public bodies or consumers in regulated markets.
Why it matters
Accessibility is now a legal requirement for many digital products and a common tender requirement.
Applies in
Worldwide; legally referenced in the EU, US, UK, India and elsewhere
Test with automated tools and manual keyboard and screen reader checks
Publish an accessibility statement
Fix issues found and test new releases
European Accessibility Act
European Accessibility Act, Directive (EU) 2019/882 on the accessibility requirements for products and services
LawMandatory if in scopeEU
The European Accessibility Act requires listed products and services sold in the EU to be accessible to people with disabilities, applying since 28 June 2025. It covers e-commerce, consumer banking, e-books, electronic communications, transport ticketing, computers, smartphones, self-service terminals and their software. In practice websites and apps are expected to meet EN 301 549, which incorporates WCAG Level AA. Micro-enterprises providing services are exempt.
Covers, who needs it and key requirements
What it covers
Accessibility requirements for listed products and services, including websites and mobile apps for e-commerce and banking, plus documentation and conformity duties.
Who needs it
Businesses selling covered products or services to EU consumers, and the agencies and software firms that build their websites and apps.
Why it matters
EU clients now need accessible websites and apps by law, so development contracts include accessibility requirements.
