Reference guide to 30+ software-engineering standards across the development lifecycle. The benchmarks expert witnesses cite to assess whether a supplier followed accepted practice in an IT dispute.
When a software project fails, the question I’m asked most often is deceptively simple: “Did they do it properly?” The failure has usually shown up as missed deadlines, budget overruns, or systems that simply didn’t work.
What solicitors and their clients really mean is: “Did the IT supplier follow recognised industry standards and best practices across the software development lifecycle?” In a CPR Part 35 expert report, that question reduces to whether the supplier’s conduct departed from accepted practice. Accepted practice is defined by the standards collected in this reference.
After 20+ years in software engineering and now specialising as a technical advisor and expert witness for IT disputes in the UK, I’ve built a comprehensive reference library of standards, frameworks, models and authoritative texts that help answer this question objectively.
This post shares that library. Whether you’re a business facing a pre-litigation dispute, a solicitor instructing an expert, or you simply want to understand what “good” looks like in software development, this reference library provides the checkpoints that matter.
Why Standards Matter in Software Disputes
In UK civil litigation, disputes involving failed software projects typically hinge on whether parties met their contractual obligations and professional duties. When an IT supplier claims they delivered “industry-standard work,” or a client alleges the IT supplier was negligent, expert witnesses must reference objective benchmarks.
These benchmarks come from:
- International standards bodies (ISO/IEC, IEEE)
- Industry frameworks (ITIL, PRINCE2, Agile)
- Professional bodies (IIBA, ISTQB, BCS)
- Authoritative practitioner texts (Code Complete, Accelerate)
- Research-backed methodologies (DORA metrics, Lean principles)
The standards below represent the core references I use when conducting technical discovery and preparing expert witness reports under CPR Part 35.
The standards collected here carry different weight in pleadings. A few are binding by regulation: non-compliance with the UK Data Protection Act 2018, or with PCI-DSS for payment systems, isn’t a stylistic preference but a legal or contractual obligation. Most of the ISO/IEC and IEEE standards are voluntary, but commonly pinned by contract: ISO 27001 isn’t mandatory by law, but a contract requiring “ISO 27001-aligned controls” makes it so for that engagement. Beyond these, the framework references (ITIL, PRINCE2, Agile, SWEBOK) are widely-cited bodies of professional practice; departures from them need to be argued as departures from accepted practice, not as breaches of regulation.
Practitioner texts like Code Complete, Clean Code, the Phoenix Project, and the DORA metrics sit at the lightest end: they’re authoritative reference works rather than binding standards. They underwrite the standard of care a court would expect of a competent professional, but no individual project is in breach for not applying them. The distinction matters in correspondence: the argument a solicitor makes depends on which kind of authority each cited standard carries.
The procedural framework that governs how those benchmarks are cited matters as much as the benchmarks themselves. Under CPR Part 35 and Practice Direction 35, an expert’s overriding duty is to the court, and the Ikarian Reefer duties shape how a standard appears in a report: cited precisely with the edition that was current at the time of the supplier’s conduct, explained in plain terms the court can adopt, applied to evidence with a stated methodology, and qualified where the standard’s application is contested in the field. A standard correctly cited and properly applied is a citable position. A standard waved at without methodology is rhetorical noise.
Keeping This Reference Current
Software engineering standards evolve. New editions of ISO standards are published. ISTQB updates its syllabi. The BABOK gets revised. The OWASP Top 10 changes as new vulnerabilities emerge.
Part of my ongoing professional development is maintaining currency with:
- Standards updates from ISO/IEC, IEEE
- New releases of foundational texts (recent editions of SRE books, DevOps practices)
- Emerging practices (platform engineering, FinOps, AI/ML engineering)
- Regulatory changes (data protection, sector-specific regulations)
When I’m instructed as an expert witness, I ensure I cite the standards that were current at the time of the project. Sometimes this means referencing superseded standards, because that’s what the industry was following when the contract was signed.
Apply These Standards to Your Case
Download my free Software Standards Assessment Checklist to evaluate whether your project followed the industry standards below.
If Your Dispute Involves…
Solicitors usually arrive at this reference with a specific dispute in mind. The categories that follow cluster by knowledge area, but common dispute types often route to the same specific categories. The following is a starting point (but not a substitute for reading the relevant section in full).
- Failed go-live or missed deadlines → Sections 1 (Requirements), 4 (Testing), 6 (Project Management)
- Scope creep and “not what we asked for” claims → Sections 1 (Requirements), 6 (Project Management)
- Production outages or stability failures → Sections 2 (Architecture), 4 (Testing), 5 (Deployment & Operations)
- Poor code quality or unmaintainable systems → Sections 3 (Construction & Code Quality), 4 (Testing)
- Security breach or data loss → Sections 3 (Construction: secure coding), 7 (Security & Compliance)
- Regulatory non-compliance (GDPR, PCI-DSS, sector-specific) → Section 7 (Security & Compliance)
- Performance or scalability failures → Sections 2 (Architecture), 5 (Deployment & Operations)
- Disputed Agile or Scrum delivery → Sections 4 (Testing: TDD/BDD), 6 (Project Management: Scrum, SAFe)
- Architectural decisions causing technical debt → Sections 2 (Architecture), 3 (Code Quality)
Most disputes draw on more than one category. The Section 1 standards on requirements, in particular, are relevant to almost every dispute. Questions about quality, scope, delivery, and acceptance often trace back to whether what was being built was adequately defined in the first place.
1. Requirements Engineering & Business Analysis
When these matter in disputes: Scope creep, ambiguous requirements, undocumented change requests, “not what we asked for” claims.
Key Standards & References:
ISO/IEC/IEEE 29148:2018 - Requirements Engineering
Why it matters: International standard for requirements processes, from elicitation through validation. When disputes involve requirements management, this standard defines what “good practice” looks like.
Common dispute applications: Were requirements properly documented? Was there a requirements baseline? Were changes managed through formal change control?
BABOK Guide v3 (Business Analysis Body of Knowledge)
Why it matters: Published by the International Institute of Business Analysis (IIBA), BABOK defines business analysis practices, techniques, and deliverables.
Common dispute applications: Did the BA properly elicit stakeholder needs? Were business requirements traceable to system requirements? Was requirements prioritisation documented?
Volere Requirements Specification Template
Why it matters: Widely cited standard for requirements completeness. Provides a checklist of what a complete requirements specification should contain.
Common dispute applications: Were non-functional requirements documented? Were acceptance criteria defined? Were constraints and assumptions captured?
MoSCoW Prioritisation
Why it matters: Standard method for prioritising requirements (Must have, Should have, Could have, Won’t have). Essential in disputes about scope and what was “promised.”
Common dispute applications: Was there documented agreement on priority? When features were dropped, were they originally MoSCoW’d as “Could have”?
IEEE 830-1998 - Recommended Practice for Software Requirements Specifications
Why it matters: Although superseded by IEEE 29148, still frequently referenced in contracts and industry practice.
Common dispute applications: Historical benchmark for what constitutes a proper SRS document.
2. Architecture & Design
When these matter in disputes: Scalability failures, architectural decisions causing technical debt, “not fit for purpose” claims, system integration failures.
Key Standards & References:
ISO/IEC 42010:2011 - Architecture Description
Why it matters: International standard for documenting system and software architecture. Defines what an architecture description should contain.
Common dispute applications: Was the architecture documented? Were architectural decisions and rationale recorded? Were stakeholder concerns addressed in the design?
C4 Model (Simon Brown)
Why it matters: Modern, widely-adopted approach to software architecture documentation using Context, Container, Component, and Code diagrams.
Common dispute applications: Did the supplier provide adequate architectural documentation? Could developers understand the intended design?
The Twelve-Factor App
Why it matters: Methodology for building cloud-native, scalable applications. Industry standard for SaaS and modern web applications.
Common dispute applications: For cloud-based systems, were twelve-factor principles followed? Were configuration, backing services, and logging handled correctly?
TOGAF (The Open Group Architecture Framework)
Why it matters: Enterprise architecture framework. Relevant in large-scale system implementations and enterprise integrations.
Common dispute applications: Was an enterprise architecture approach used when appropriate? Were architectural governance processes followed?
Design Patterns (Gang of Four - Gamma, Helm, Johnson, Vlissides)
Why it matters: Foundational text on reusable software design solutions. Establishes professional design practices.
Common dispute applications: Did developers follow recognised design patterns? Were complex problems addressed with proven solutions rather than bespoke code?
3. Software Construction & Code Quality
When these matter in disputes: Poor code quality, unmaintainable systems, technical debt, “spaghetti code,” security vulnerabilities.
Key Standards & References:
Code Complete 2 (Steve McConnell)
Why it matters: Considered the definitive practitioner guide to software construction. Covers coding practices, debugging, testing, and professional discipline.
Common dispute applications: Did developers follow professional coding standards? Were code reviews conducted? Was defensive programming practiced?
Clean Code (Robert C. Martin)
Why it matters: Industry-standard guide to writing readable, maintainable code. Establishes expectations for variable naming, function size, comments, and structure.
Common dispute applications: Is the codebase maintainable? Did developers write code that another competent developer could understand and modify?
ISO/IEC 25010:2011 - Systems and Software Quality Requirements and Evaluation (SQuaRE)
Why it matters: International standard defining software quality characteristics: functionality, reliability, usability, efficiency, maintainability, portability.
Common dispute applications: Did the delivered software meet quality characteristics implied by “fit for purpose”? Were quality requirements defined and met?
OWASP Top 10
Why it matters: De facto standard for web application security vulnerabilities. Updated regularly to reflect current threats.
Common dispute applications: Did developers follow secure coding practices? Were known vulnerabilities addressed? Was security testing conducted?
SonarQube Quality Profiles
Why it matters: Widely-used static code analysis tool with language-specific quality profiles. Establishes automated quality gates.
Common dispute applications: Was automated code quality measurement used? Did code meet basic quality thresholds (code coverage, complexity, duplications)?
MISRA C/C++
Why it matters: Coding standards for safety-critical and embedded systems. Essential in automotive, medical devices, aerospace.
Common dispute applications: In safety-critical systems, were MISRA standards followed? Were deviations documented and justified?
4. Testing & Quality Assurance
When these matter in disputes: Untested releases, production failures, inadequate testing, “did they even test this?” claims.
Key Standards & References:
ISO/IEC/IEEE 29119 - Software Testing (5 parts)
Why it matters: International standard covering test concepts, processes, documentation, techniques, and keyword-driven testing.
Common dispute applications: Was testing planned and documented? Were test strategies appropriate to risk? Were test results recorded and defects tracked?
ISTQB (International Software Testing Qualifications Board) - Foundation and Advanced Syllabi
Why it matters: Globally recognised testing qualification and body of knowledge. Defines professional testing practices.
Common dispute applications: Did testers have appropriate qualifications? Were recognised testing techniques used (equivalence partitioning, boundary value analysis, etc.)?
Test Pyramid (Mike Cohn)
Why it matters: Industry-standard model for test automation ratio: many unit tests, fewer integration tests, few UI tests.
Common dispute applications: Was the test automation strategy appropriate? Was there over-reliance on manual testing or expensive UI tests?
Behavior-Driven Development (BDD) / Test-Driven Development (TDD)
Why it matters: Recognised development methodologies that embed testing into the development process.
Common dispute applications: If TDD/BDD was promised in the contract, was it actually practiced? Is there evidence of tests being written first?
Chaos Engineering Principles
Why it matters: Modern approach to resilience testing, particularly for distributed systems and microservices.
Common dispute applications: For mission-critical systems, was resilience testing conducted? Were failure scenarios tested?
5. Deployment, DevOps & Operations
When these matter in disputes: Production outages, deployment failures, inadequate monitoring, incidents caused by rushed releases.
Key Standards & References:
Accelerate (Forsgren, Humble, Kim) & DORA Metrics
Why it matters: Research-backed book establishing four key DevOps metrics: deployment frequency, lead time for changes, mean time to restore, change failure rate. Industry benchmark for delivery performance.
Common dispute applications: Were deployments frequent and low-risk? Was lead time from commit to production reasonable? Were failed deployments quickly remediated? What was the change failure rate?
The Phoenix Project & The DevOps Handbook (Gene Kim et al.)
Why it matters: Foundational texts on DevOps culture and practices. Establishes principles for continuous delivery, feedback, and learning.
Common dispute applications: Were DevOps practices followed when claimed? Was there collaboration between development and operations? Were deployments automated?
Site Reliability Engineering (Google SRE Book)
Why it matters: Google’s approach to running production systems reliably. Establishes SRE principles including error budgets, SLIs/SLOs/SLAs, and incident management.
Common dispute applications: Were reliability targets defined? Was monitoring adequate? Were incidents managed professionally with post-mortems?
ITIL 4 (IT Infrastructure Library)
Why it matters: Widely-adopted framework for IT service management. UK government standard for many public sector projects.
Common dispute applications: Were ITIL processes followed when contractually required? Was change management, incident management, and problem management conducted properly?
ISO/IEC 20000 - Service Management
Why it matters: International standard for IT service management, aligned with ITIL.
Common dispute applications: In managed service contracts, were service management standards met? Were SLAs monitored and reported?
6. Project Management & Governance
When these matter in disputes: Timeline failures, budget overruns, scope creep, inadequate project controls, communication breakdowns.
Key Standards & References:
PRINCE2 (Projects IN Controlled Environments)
Why it matters: UK government standard for project management. Widely used in public sector and large private sector projects.
Common dispute applications: Were PRINCE2 processes followed when contractually required? Were project boards established? Were stage gates used? Was risk managed through the risk register?
PMBOK (Project Management Body of Knowledge)
Why it matters: Project Management Institute’s standard, covering 10 knowledge areas and 5 process groups.
Common dispute applications: Were professional project management practices followed? Were appropriate PM tools and techniques used?
ISO 21500:2012 - Guidance on Project Management
Why it matters: International standard providing guidance on project management concepts and processes.
Common dispute applications: Generic benchmark for project management professionalism.
Scrum Guide (Schwaber & Sutherland)
Why it matters: Definitive guide to the Scrum framework. Essential reference when projects claim to be “Agile.”
Common dispute applications: If Scrum was used, were Scrum practices actually followed? Were sprints conducted properly? Were ceremonies held? Were roles (Product Owner, Scrum Master) fulfilled?
SAFe (Scaled Agile Framework)
Why it matters: Framework for scaling Agile to large enterprises. Common in large organisations claiming to be “Agile at scale.”
Common dispute applications: In large Agile transformations, were SAFe practices followed? Were Program Increments planned? Were Agile Release Trains established?
Agile Practice Guide (PMI & Agile Alliance)
Why it matters: Complementary guide to PMBOK for Agile projects. Bridges traditional and Agile project management.
Common dispute applications: Were Agile principles followed? Was there genuine iterative development with customer feedback?
7. Security & Compliance
When these matter in disputes: Data breaches, security vulnerabilities, regulatory non-compliance, inadequate security testing.
Key Standards & References:
ISO/IEC 27001/27002 - Information Security Management
Why it matters: International standard for information security management systems (27001) and security controls (27002).
Common dispute applications: Were security controls adequate? Was information security managed systematically? Were risk assessments conducted?
NIST Cybersecurity Framework
Why it matters: US National Institute of Standards and Technology framework for managing cybersecurity risk. Widely adopted globally.
Common dispute applications: Were cybersecurity risks identified, protected against, detected, responded to, and recovered from?
OWASP ASVS (Application Security Verification Standard)
Why it matters: Application security testing checklist and benchmark. Three verification levels for different risk profiles.
Common dispute applications: Was security testing conducted? Were security requirements defined? Was penetration testing performed?
CIS Controls (Center for Internet Security)
Why it matters: Prioritised set of cybersecurity best practices. Version 8 contains 18 controls.
Common dispute applications: Were basic security controls implemented? Was there inventory of assets, data protection, access control, etc.?
PCI-DSS (Payment Card Industry Data Security Standard)
Why it matters: Mandatory standard for handling credit card data. 12 requirements covering network security, cardholder data protection, vulnerability management, etc.
Common dispute applications: If payment processing was involved, was PCI-DSS compliance achieved and maintained? Were security audits conducted?
GDPR & UK Data Protection Act 2018
Why it matters: Legal requirements for processing personal data in the UK. Not optional.
Common dispute applications: Was personal data handled lawfully? Were data protection by design principles followed? Was a DPIA conducted when required?
How Standards Become Evidence
A reference library is the start, not the end. A standard becomes evidence in a software dispute when an expert can name it precisely, identify the edition that was current at the time of the supplier’s conduct, set out the supplier’s actual practice against it, and explain the gap’s significance in terms the court can adopt.
That’s the procedural shape of a CPR Part 35 expert report. The expert isn’t asked whether industry standards exist; the expert is asked whether the supplier’s conduct departed from accepted practice on the facts of this matter, and the standards are the lens through which “accepted practice” is defined. Each cited standard needs the same treatment:
- The standard, named precisely. “ISO/IEC 27001:2013” not “ISO 27001”. “ISO/IEC/IEEE 29148:2018” not “the requirements standard”. Editions matter because the standard at the time of the project is what governs, not the version current today.
- The standard’s status. Whether it’s binding by regulation or contract, voluntary but contractually pinned, an industry-accepted body of practice, or a practitioner text underwriting the standard of care. The four levels carry different argumentative weight.
- The supplier’s actual practice. Evidenced from the project record: code repositories, test records, deployment logs, change-control history, communication between the parties. The expert cites what was done; the standard provides the benchmark.
- The gap, characterised. Whether the departure was a stylistic choice within accepted variability, a documented deviation justified at the time, a material departure unsupported by the project context, or a failure to apply the standard at all. Not all gaps carry the same significance.
- The methodology, stated. Under the Ikarian Reefer duties, the expert’s opinion has to be reasoned, not asserted: the reader of the report should be able to see how the expert moved from evidence and standard to conclusion. Where the application of a standard is contested in the field, the expert says so and qualifies.
Done properly, a standard becomes a citable position that the opposing expert has to engage with seriously. Done loosely, citation of a standard is rhetorical noise. The opposing expert points out the missing edition, the unstated methodology, or the contested application, and the citation falls away.